Encryption & Key Management , Next-Generation Technologies & Secure Development , Security Operations

Draft Encryption Policy Meets Swift Demise

Amid Public Backlash, Government Withdraws Document Within Two Days
Draft Encryption Policy Meets Swift Demise

The draft document for India's National Encryption Policy, released for public comment on Sept. 19, was withdrawn on Sept. 22 by the Department of Electronic and Information Technology following a severe backlash from the public. While the release was intended to foster healthy debate in the public, leading to quality input toward the final document, the draft ended up receiving widespread criticism via social media and other online channels.

See Also: Cyber Insurance Assessment Readiness Checklist

Following the furor, Indian Telecom Minister Ravi Shankar Prasad instructed DeITY to withdraw the document and rework it, before re-releasing it in the public domain. The main points of contention revolve around the requirement that individual citizens store plain text versions of all encrypted communication for a period of 90 days, to be made available to law enforcement on demand. In addition, the government reserved the right to prescribe the key-strength, algorithms and ciphers. Further, only government-notified encryption products and vendors registered with a designated agency setup for this purpose would be allowed to conduct business.

The combination of these requirements essentially negated the objective of encryption itself, many experts believe. "In security, you cannot get any assurance by deliberately weakening systems, which is what this draft proposes," says Akash Mahajan, director of Bengaluru-based service provider, The App Sec Lab.

Rather than try to crack encrypted communication, an attacker would now have 90 days to access the plain text, Mahajan tweets.The draft has also been perceived by some as impinging upon an individual's right to even delete digital communication that they participate in.

In response to the strong objections being raised, the government proposed an addendum to the draft policy published late on Sept. 21 - which was also taken down a day later - clarifying that the use of 'mass-encryption' products, defined as TLS and SSL, were exempt. This includes their use in Web services, social media, applications, Internet banking, payment gateways, e-Commerce and password-based transactions.

At a press conference in Delhi on Sept. 22, Telecom Minister Ravi Shankar Prasad emphasized that this was a "draft," which only applied to "creators"' of encryption and not users of consumer apps that use encryption, such as instant messengers. However, experts say that the policy is ambiguous in this regard. For example, if a PC or smartphone uses a hardware/software module to perform full-disk encryption, does that make the user a "creator" of encryption?

Upon reaching out for details on the expert group, inside sources at DeITY told Information Security Media Group, that the atmosphere internally was one of confusion. The entire department was tense as the government has asked for an explanation of the debacle within hours of publicly disavowing the draft.

Policy for Snooping?

The contentious requirements broadly point at a data retention and surveillance regime to assist intelligence and law enforcement agencies, experts suggest. Telecom Minister Prasad also noted in his press conference that the security concerns from the rising use of encryption is obvious, and India needs an encryption policy within the ambit of the Information Technology Act 2000.

Sunil Abraham, executive director of the Bangalore-based Centre for Internet and Society, says the proposed policy could be broadly divided it into three parts. The first two parts appear to deal with setting standards in security and building indigenous capacity in areas like cryptography and encryption. The third part, however, is completely at odds with first two and reads like a data retention/surveillance plan, which compromises the first two objectives, he says.

"It's a mix of many things; it's a very complicated topic and I'm afraid they've muddled it up terribly," he says. "They could instead have come out and clearly said that this was for surveillance and legal interception."

This could have been a data retention policy, updated for the social media and digital age, he says, requiring large companies that store encrypted data to comply with legal intercept requirements. There are requirements that this policy makes of individual citizens which simply cannot be enforced, he notes.

"Ideas like key escrow have remained the fantasy of governments around the world for many years," Abraham says. "But it's a terrible Idea from a security standpoint."

To what degrees private players/entities would have complied with such a policy, especially multi-national ones, is unclear. They could have made broad outlines in terms of data retention, although private entities may not be willing or able to comply, he says. For instance, no one has complied with the Department of Telecom note from 2007, limiting the use of symmetric encryption in India to 40 bits - including public sector banks, which are mandated by RBI to use a minimum of SSL/128 bit encryption since 2001.

Policy Apparatus Lacks Maturity

App Sec Lab's Mahajan says the draft document's approach to encryption is superficial. "The document alternately mentions encryption and cryptography, which are not the same," he says. It also ignores anything relating to embedded devices and wearables, all of which use encryption. How do you store this information in plain text? "Going by the policy, will anyone using an open source Linux OS - in keeping with Digital India's open source dreams - be doing something illegal if it is not registered? How is this going to be implemented?"

It is typical of the Indian government's policies that when such policies come out, people get on their hobby horses and add all sorts of things, says CIS' Abraham. Maybe it started off with an interception and data retention policy, and the other elements got tacked on, he suggests. The inherent contradictions in the document reflect a lack of clarity on the policy objective, he adds.

The government is trying to interfere with the standards process when it dictates what the market should be doing, Abraham believes. "This is the wrong way to regulate technology; it's overreaching," he says.

Sensible governance requires a keen insight of regulatory capacity and enforcement ability. "Something as impractical as this makes a mockery of government policy; DeITY's present draft would have overreached on both counts." Abraham says. "The government has neither the capacity to regulate encryption, nor to enforce this policy, if passed into law"

The lesson for future efforts at writing technology policies is that technology should not ideally be regulated, he believes. "What you want to regulate is the behavior of corporations; you should not be dictating technical nitty-gritties to the market," he advises. "Always be conservative in new regulation, and monitor developments in other jurisdictions, lest the industry stop taking you seriously."

Forcible regulation stymies innovation and cripples startups, Mahajan believes. This draft would have required all software utilizing encryption to be rewritten. "With 30 percent of Indian exports being in software, how does the government plan to justify this decidedly immature move globally?" he asks.

About the Author

Varun Haran

Varun Haran

Managing Director, Asia & Middle East, ISMG

Haran has been a technology journalist in the Indian market for over six years, covering the enterprise technology segment and specializing in information security. He has driven multiple industry events such as the India Computer Security Conferences (ICSC) and the first edition of the Ground Zero Summit 2013 during his stint at UBM. Prior to joining ISMG, Haran was first a reporter with TechTarget writing for SearchSecurity and SearchCIO; and later, correspondent with InformationWeek, where he covered enterprise technology-related topics for the CIO and IT practitioner.

Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing databreachtoday.com, you agree to our use of cookies.