Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

5/21/2008
06:32 PM
George V. Hulme
George V. Hulme
Commentary
50%
50%

Research In Motion May Hand Crypto Keys To Indian Government

Apparently, the Indian government can't crack 256-bit encryption to read protected e-mails on RIM BlackBerrys. It appears RIM is willing to lend a hand, by handing over its (your) keys.

Apparently, the Indian government can't crack 256-bit encryption to read protected e-mails on RIM BlackBerrys. It appears RIM is willing to lend a hand, by handing over its (your) keys.According to this story, which ran today in The Economic Times, there's been somewhat of a riff between the Indian Department of Telecom and RIM over BlackBerry's inherently robust (until now) encryption.

Apparently, the Indian government can only break crypto if it's 40 bits, or less. So they asked RIM to fork over the keys that make it possible to decrypt the messages or reduce BlackBerry crypto to 49 bits.

From the story:

According to officials close to the development, Canadian High Commissioner David Malone and RIM officials met telecom secretary Siddhartha Behura on May 7. "It was explained by RIM that it should be possible for the government to monitor e-mails to nonbusiness enterprise customers," sources told ET. "RIM is considering giving access to individual users' e-mail to the government. Details on this will be provided in two or three weeks," sources said.

So it appears, for now, that corporate users don't have as much to be concerned with.

RIM doesn't have much more to say on the issue:

A RIM spokesperson said: "RIM operates in more than 135 countries around the world and respects the regulatory requirements of governments. RIM does not comment on confidential regulatory matters or speculation on such matters in any given country."

I hope RIM grows more of a backbone and "respects" the privacy and security needs of its customers.

Once the keys are public, how long before the cryptography scheme is broken? How long before they're sold to criminals? And where does this stop? Are keys going to be made available to any government that asks?

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
Why Vulnerable Code Is Shipped Knowingly
Chris Eng, Chief Research Officer, Veracode,  11/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-16123
PUBLISHED: 2020-12-04
An Ubuntu-specific patch in PulseAudio created a race condition where the snap policy module would fail to identify a client connection from a snap as coming from a snap if SCM_CREDENTIALS were missing, allowing the snap to connect to PulseAudio without proper confinement. This could be exploited by...
CVE-2018-21270
PUBLISHED: 2020-12-03
Versions less than 0.0.6 of the Node.js stringstream module are vulnerable to an out-of-bounds read because of allocation of uninitialized buffers when a number is passed in the input stream (when using Node.js 4.x).
CVE-2020-26248
PUBLISHED: 2020-12-03
In the PrestaShop module "productcomments" before version 4.2.1, an attacker can use a Blind SQL injection to retrieve data or stop the MySQL service. The problem is fixed in 4.2.1 of the module.
CVE-2020-29529
PUBLISHED: 2020-12-03
HashiCorp go-slug before 0.5.0 does not address attempts at directory traversal involving ../ and symlinks.
CVE-2020-29534
PUBLISHED: 2020-12-03
An issue was discovered in the Linux kernel before 5.9.3. io_uring takes a non-refcounted reference to the files_struct of the process that submitted a request, causing execve() to incorrectly optimize unshare_fd(), aka CID-0f2122045b94.