Are you sharing more data with Google than you have to?
- by 7wData
Whether your concerns are privacy, security, competitive advantage, intellectual property or risk avoidance, your enterprise needs to be sharing — literally — as little data as possible with employees, contractors and third parties. As obvious as that statement is, it’s stunning how much data is unnecessarily shared with cloud providers and others.
There are two reasons for this. First, the time and effort needed to be remove data that the third party doesn’t truly need from the data that isneeded can make the ROI seem unattractive. This is especially true when executives play down the risk of anything bad happening.
As in "I’m probably safe trusting Google/Microsoft/Amazon/Rackspace, etc." Really? Even if you choose to assume that their security is stellar — it isn’t — what about competitive issues? Are you really willing to trust that they will handle your data with your best interests at heart?
The second reason is more practical: technological limitations. The way many enterprises handle data — especially data that is either created by or managed by mobile devices — makes it truly difficult to easily separate the critical from the non-essential.
Researchers at the Swiss Federal Institute of Technology in Lausanne — officially the École Polytechnique Fédérale De Lausanne (EPFL) — may have come up with a way to deal with both issues. Their approach limits what data is shared and uses an encryption approach that allows data to be crunched while still encrypted.
The approach they are proposing is designed to deal with a very limited issue: privacy and security issues involving ride-sharing services such as Uber and Lyft. But its creators see the same approach applying to a wide range of cloud, big data and other third-party services that enterprises deal with every day — when they are typically sharing far more information than they need and want to.
Italo Dacosta, an EPFL postdoctoral researcher involved in the project, cited hospitals that "in the context of personalized medicine, want to do computations on the DNA sequence" and seek a cloud firm to help with the complex number-crunching. "Patients may not be comfortable sharing the DNA sequence because it’s so sensitive," he said in a Skype interview with Computerworld.
"Homomorphic encryption patients will not have to reveal their DNA sequence at all, not even partially," Dacosta said. "The main use case for Homomorphic encryption for personalized medicine is allowing researchers/doctors from other hospitals/medical institutions to analyze genomic data without having to reveal the data to them. They only see the results of their queries and analysis."
The third parties "never see the real data but you get the results from the computations. [Third parties] don’t need to see the data (as they) can crunch the data while it’s encrypted."
The researchers are publishing their source code and full implementation details, in the hope that companies will adopt the approach. They deliberately have avoided patenting the approach, preferring companies to use it for free, Dacosta said.
The approach, detailed in this paper, involves Somewhat-Homomorphic Encryption (SHE). (Note: Stanford University has published a short description of SHE.)
This excerpt, from that paper, gives the overview of the technical approach: "SHE cryptosystems present semantic security, i.e., it is not (computationally) possible to know if two different encryptions conceal the same plaintext. Therefore, it is possible for a party without the private key to operate on the ciphertexts produced by riders and drivers, without obtaining any information about the plaintext values. Additionally, we choose one of the most recent and efficient SHE schemes based on ideal lattices, the FV scheme. This scheme relies on the hardness of the Ring Learning with Errors (RLWE) problem.
[Social9_Share class=”s9-widget-wrapper”]
Upcoming Events
From Text to Value: Pairing Text Analytics and Generative AI
21 May 2024
5 PM CET – 6 PM CET
Read More