The Draft Encryption Policy - An impractical exercise

The government of india published a new draft encryption policy . Frankly a part of me still imagines this to be an April fools prank gone awry. And that I will wake up tomorrow to news, that this was a screwup and we can all forget about it.

[EDIT: The government has since published an addendum, issuing clarifications. PROPOSED ADDENDUM TO THE DRAFT ENCRYPTION POLICY This post has been updated at the end to reflect the same. In brief while it has reduced the coverage of the applications and services, the essential implementation issues as pointed out to in this post still remain and the policy seems just as silly and onerous after the addendum was published.]

Be as it may, this policy has received substantial criticism early on, not the least of which is about the various privacy issues. This post attempts to look at this policy within the context of security, practicality and law.

Note that encryption as referred to in this policy applies to encryption as used for transmission AND storage. Also the quoted policy text may refer to G, B and C. This refers to Government, Business and Citizens respectively.

An imaginary conversation

I am frankly dumbstruck by the policy draft. I wonder how it even resulted into its current state. My best guess is somewhere in the policy corridor a conversation along the lines below happened. Once again, to emphasise, the conversation below is imaginary.

Politician: We need to have a better ability to intercept all the messages flowing on the internet. Very needed to take on terrorism and is also useful for political intelligence and rapid reaction.

Bureaucrat: Sir, most of the internet sites and mobile apps encrypt all the conversations. So even as we can readily intercept the messages, we cannot easily decrypt them.

Politician: But the US does it. Why can't we as well?

Bureaucrat: Ahh, but they have the NSA and all its resources, and they can arm twist the large internet giants into making backdoor concessions via programs such as PRISM as Edward Snowden showed. They even introduced backdoors into the Dual Elliptic Curve random number generation written by RSA to easily crack the encryption. We cannot do that.

Politician: Lets have the chinese model then.

Bureaucrat: Ahh .. but there there is far more interception of messages and an ability to do better offline monitoring of suspicious citizens, and the government can easily get to the data of a suspicious guy, because there is lesser judicial oversight. We being a democracy with an active judiciary cannot implement that model either.

Politician: OK, I don't really care for the encryption per se. And I don't wish to be lambasted for too much snooping. Just make sure that we can easily access the non encrypted data directly from one of the parties when we need to and there is enough of a legal framework to support that.

Bureaucrat: OK Sir.

The said bureaucrat then sets in motion a series of actions which results in this new draft policy document

Comments on the draft

Lets first take a tour through some of the interesting provisions in the new so called policy.

Use of encryption algorithms and protocols

Use of Encryption technology for communications between G group and B / C groups (i.e. G2B and G2C sectors) with protocols and algorithms for encryption, key exchange, Digital Signature and hashing will be as specified through notification by the Government from time to time.

So the government will decide what kind of algorithms and protocols can be used. Businesses may no longer retain the liberty to choose which algorithms and protocols they may use or use any custom algorithms (even though that is not such a good idea, the freedom to use it is), or innovate to create better algorithms. The government dicates and businesses shall oblige.

Ability to reproduce encryption using software/hardware

On demand, the user shall be able to reproduce the same Plain text and encrypted text pairs using the software / hardware used to produce the encrypted text from the given plain text.

Whenever business do any kind of encryption, they must be able to reproduce both the plain text and the encrypted text.

First of all, if the key has any random or varying element to it the encrypted text may not be the same each time. But no, the government now mandates that you must be able to produce the same encrypted text from the given plain text as you did earlier. Randomness be damned. Which means in case of random keys, the keys will need to get stored as well.

Secondly the user needs control over the software and hardware used to produce the encrypted text. So if you had a cloud based service to do it for you, you would need to find a way to ensure that you are able to re-do the same using the cloud based service on the day the government makes that request of you, and if your cloud based service cannot do it for you, that will now be you the consumer's fault. Or if you are using a mobile app you should be able to reproduce both the plain text and the encrypted text pair along with the key.

Storage of plain text for 90 days

This is a huge huge huge deal and perhaps the hardest part of this policy to deal with. As per the policy

Such plain text information shall be stored by the user/organisation/agency for 90 days from the date of transaction and made available to Law Enforcement Agencies as and when demanded in line with the provisions of the laws of the country

It further goes on to add

In case of communication with foreign entity, the primary responsibility of providing readable plain-text along with the corresponding Encrypted information shall rest on entity (B or C) located in India.

Elsewhere the document states

All information shall be stored by the concerned B / C entity for 90 days from the date of transaction and made available to Law Enforcement Agencies as and when demanded in line with the provisions of the laws of the country. In case of communication with foreign entity, the primary responsibility of providing readable plain-text along with the corresponding Encrypted information shall rest on entity (B or C) located in India

We will get into a number of issues this creates later on. But just the basic implementation is impractical. The browser exchanges literally hundreds if not thousands or more encrypted messages with various servers every hour. How is one expected to keep a log of all these exchanges? Both the plain text and encrypted bodies. And you have to store the keys as well since these keep on changing. How will this work with mobile apps ? Most internet services and mobile app servers are based abroad. So the entire burden of responsibility comes down on the lay user residing in India. What if the mobile is stolen and the government asks for that data in less than 90 days since it was generated? What if you delete some data (eg. messages) after you had exchanged them? What about applications that use different protocols for encryption? This is a complete nightmare. Lay users will simply not be able to even comprehend what needs to be done and how, forget actually taking on the responsibility to implement this. The only practical way out is to stop using computers and modern smart phones and go back to the PCs of the 80s without the internet and old Nokia phones which maintain an address book and an ability to make calls.

Service provider registration

Service Providers located within and outside India, using Encryption technology for providing any type of services in India must enter into an agreement with the Government for providing such services in India. Government will designate an appropriate agency for entering into such an agreement with the Service provider located within and outside India. The users of any group G,B or C taking such services from Service Providers. are also responsible to provide plain text when demanded.

There are literally thousands of websites and mobile app services that use encryption. Are they supposed to enter an agreement with the Government of India?

The policy further goes on to add in a separate section

Registration: All vendors of encryption products shall register their products with the designated agency of the Government. While seeking registration, the vendors shall submit working copies of the encryption software / hardware to the Government along with professional quality documentation, test suites and execution platform environments. The vendors shall work with the designated Government Agencies in security evaluation of their encryption products. Complete confidentiality will be maintained in respect of information shared by the vendors with designated agency. The vendors shall renew their registration as and when their products are upgraded. Mass use products like SSL / TLS are exempted from registration.

This is just ridiculous. What an encryption product is is not clear. SSL/TLS are classfied as products (they are not). Such vendors shall submit working copies of software / hardware to government along with professional quality documentation, test suites and execution platforms? So some small startup somewhere buys a piece of helpful hardware to help with the encryption, it now has to buy another one just to deposit it with Government of India? Assuming the GOI is capable enough to accept such software/hardware, the startup will now need to provide detailed documentation. Assuming one gets past that, anyone who has the slightest confidence that the government has the necessary resources and skills to deal with thousands of such submissions may please raise their hand. For a government claiming to be pro-startups, its hurting them hard.

Please note: SSL/TLS are exempted from registration, not from the onerous requirement of storing 90 days of plain text, encrypted data and the session keys

The document further goes on to state

The Government will notify the list of registered encryption products from time to time, without taking responsibility for security claims made by the vendors.

So even after this, each user is left to sift through a list of "registered encryption products" to figure out if their preferred web site or mobile app may be used in India. Every traveler to India will need to do the same as well when in India.

Lack of a legal framework

The document adds

Government reserves the right to take appropriate action as per Law of the country for any violation of this Policy.

Ummm right. Under what IPC will you charge a user for deleting a Whatsapp message? Where is the legal framework which tells the citizens of the country what maximum jail time or penalties they might face if found in violation? What if the phone got stolen? Does that make his penalty any less? Where is the legal framework for prosecuting violations of this policy? Or the clarity if one does exist.

Promotion of R&D in cryptography

With a view to promote the R&D into cryptography the document states

Research and Development programs will be initiated for the development of indigenous algorithms and manufacture of indigenous products for Encryption, hashing and other cryptographic functions. These will be carried out by Public and Private Sector / Government Agencies and Academia. Continuous intensified R&D activities in the niche areas of technical analysis and evaluation of Encryption products will be strengthened.

Nice sounding. But the entire tenor of the document is meant to make encryption so onerous that people will run a thousand miles away from it. This document essentially screams "DO NOT ENCRYPT". In such an environment one wonders why the government actually needs to promote indigenous algorithms and products when it intent seems to be strongly focused on completely destroying such a market (and the IT, BPO and Knowledge Processing industries as stated later).

Algorithms to be used

In the annexure the policy prescribes the algorithms to be used.

Symmetric Cryptographic/Encryption products with AES, Triple DES and RC4 encryption algorithms and key sizes up to 256 bits are prescribed by the Government for use for protecting information by stakeholders.

One wonders how much the government even hopes to support encryption when one of the three suggested algorithms has been explicitly proscribed by the Internet Engineering Task Force (IETF) under RFC 7465 from using it within TLS clients. Clearly the government seems to be unaware of what is happening on the security front and is suggesting algorithms that the Internet widely now believes to be insecure. The least they could have done was at least drop RC4. While not inconvenient, this does make one wonder how well the government is conversant with the happenings in the IT industry.

Disingenious Objectives

The document in its preamble lays down its vision, mission, and objectives. And yet after reading the rest of the document, one wonders if the government even remotely understood that its policy is almost entirely inconsistent with what it set out to do. Thus either it was not entirely honest in setting out its goals properly, or it did a rather shoddy job by actually undermining these very goals. Let us take a look at the goals themselves.

Vision

To enable information security environment and secure transactions in Cyber Space for individuals, businesses, Government including nationally critical information systems and networks.

Mission

To provide confidentiality of information in cyber space for individuals, protection of sensitive or proprietary information for individuals & businesses, ensuring continuing reliability and integrity of nationally critical information systems and networks.

Objectives

To synchronize with the emerging global digital economy / network society and use of Encryption for ensuring the Security / confidentiality of data and to protect privacy in information and communication infrastructure without unduly affecting public safety and National Security.

To encourage wider usage of Digital Signature by all entities including Government for trusted communication, transactions and authentication.

To encourage the adoption of information security best practices by all entities and Stakeholders in the Government, public & private sector and citizens that are consistent with industry practice.

I don't think a further discussion is really required as to the incogruity between the goals as set out and the implementation directives.

Implementation difficulties with this policy

Lets just run through the number of issues this creates.

What does it mean to store plain text information. Does it need to be stored as a plain text? Many mobiles and computers have fully encrypted file systems or fully encrypted databases. Will storing plain text information on such file systems or databases be allowed ? If not, will organisations and end users need to change to unencrypted file systems thus substantially compromising their security?
Continuing from above, many users (including yours truly) use full disk encryption as a mechanism to guard against accidental data leakage in case of mobile/laptop theft, loss etc. Will end users have to give up on that security? And will theft or loss of a mobile / laptop now mean someone else can easily access all the data?
If a service provider is registered, does it absolve the end user citizen from maintaining encryption logs? It does not seem so.
It seems a new market is being unintentionally created for transparently logging plain text data, encrypted text and keys used for encryption every time encryption is used for storage or transmission. This could be done at various levels
1. End users - Clearly end users cannot hope to maintain a log of all this stuff. They are more likely to give up using computers and start using and the pure mobile handsets (non smartphones) thus reversing any attempts at increasing digitisation.
2. Applications - There are again literally thousands if not hundreds of thousands of desktop and mobile applications. Does each one need to be modified now? Again exceptionally unlikely
3. Operating systems - Perhaps Windows and Android and iOS could be enhanced. But will they? And really, why should they? And that will only cover those scenarios where such encryption is done using system level libraries. Rest of the apps are still on their own.
Citizens will not be able to use web services and mobile apps that are not compliant. I mean if I edit and save an email 20 times before sending it from a mail service which stores all emails as encrypted, would an extreme interpretation mean web mail client has to save 20 triplets of plain text, encrypted text and key used for encryption? Or at least plain text and encrypted pairs? Unless the internet application or mobile application does it, no end user will be able to use it for fear of being termed a criminal
There's a deep conflict with good practices and internationals standards. As an example PCI standards. They have a substantial focus on encryption including not storing data in plain text and using random keys and securely encrypting any key information that must be stored. A credit card processor could not find a way to obey the law of the land and the mandatory requirements of secure processing as laid down by the industry. There's no way to run that business within the territorial boundaries of India.
Keys are often stored in Hardware Security Modules (HSMs) for storing them securely. No HSM manufacturer worth his salt will ever condescend to create an HSM that complies with the directives in this policy simply because it is incredibly stupid to do so. Thus enterprises would not be able to use HSMs. Even normal key storage itself would need to be extraordinarily insecure to be consistent with this policy.
I think the general extrapolation of the last two points will suggest that software engineers will need to throw out of the window all known best practices for ensuring data security and privacy, and make sure data is fully open or at least open enough to be just one step away from disclosure as and when required (which also makes it far far more easily accessible to hackers)
Assuming one does log the data, how does one ensure its availability. What happens in case of disk crash? Do mobiles now need to have RAID 5 storage?
What happens with cloud based systems like google chrome? There is little if any storage on the local systems. Do such OS's now require to be modified to cater to the encryption policy?

Political implications

There are some other serious implications in terms of required professional confidentiality (eg. with doctors and lawyers), having secure protected communications with say a spouse, whistleblowing activities, communication with journalists, political dissidence et. al. These are all communications that must be protected within any self respecting democracy.

In addition there is the very basic fundamental right citizens have to privacy.

For a government which claims to promote digitisation, it is setting out to impose a huge cost on the same. Is the policy consistent with the ambitions?

This is an explosive can of worms that threatens civil rights and encourage movement to a orwelian state.

Basically this policy document justs seems like a really bad dream. However this being a technical blog, this entire issue is not explored or commented upon further.

Commercial implications

As mentioned earlier this policy draft does not live up to its stated goals. As also further pointed out this draft basically destroys any notion of secure data storage and encourages rejecting decades of improvements in data storage best practices. But most importantly this policy if implemented (which it should not ever get there hopefully) will headline India for having a regulatory framework which totally compromises data management best practices.

This will make it hard for businesses to outsource data to Indian companies because their data will now be stored in plain text along with the necessary encryption keys. This could be disastrous for the IT, BPO and all Knowledge Processing industries.

EDIT:

The government has since published the addendum to the policy following the media uproar. PROPOSED ADDENDUM TO THE DRAFT ENCRYPTION POLICY

Since it substantially impacts this post, am documenting my thoughts regarding the same separately as follows.

What is the definition of "The mass use encryption products, which are currently being used in web applications, social media sites, and social media applications"? This is such a large category that it is impossible to imagine those who authored the original document did not think of this class of services. So I suspect this was essentially a knee jerk reaction to the uproar rather than having been thought of in the first place. Also does gmail qualify for the exemption above? Lets presume for a moment it does, does my webmail client as offered by my web host provider qualify? It is unlikely to. So some webmail clients are exempt and some aren't. Does telegram, another app similar to whatsapp qualify? The above definition does not make it clear. If I wrote a similar app for my family, Will it? If not, why not?

In short this clarification makes the whole thing even more murky.
I presume by SSL/TSL based products it means corresponding web sites. Why call them products? And there are tons of other apps which may not qualify. eg. a health care management system, or a logistics routing application. One might argue that if they are password based, then they should also be exempt. Assuming all password based services are exempt then what is the whole policy for? What non password based services need such a disturbing policy around it? And if all password based services are not exempt, then all the issues I've pointed to are still relevant. Thus leading to a scenario where a large number of internet based services and mobile apps having to deal with a real ton of issues to sort through.
What about outsourced IT, BPO and other backoffice services to India ? Do they qualify for exemption. Many of them will not meet the addendum requirement for exemption. And yet they will deal with very important sensitive data. Will the data owners continue to allow their Indian outsourcing partners to continue dealing with their data?

This whole addendum sounds like a knee jerk reaction to a really deficient policy in the first place. Seems to me this policy was a very very bad idea to begin with, something that the government simply did not think through. And now it is trying to put up a face saver using an addendum. Sadly that only deals with the issues raised in the popular media. It still does not address many of the implementation issues I have referred to. Perhaps the policy makers simply have very little clue about what is it that they are attempting to regulate. And leaving us very very confused, and very very scared.

social