One of the problems with smartphone apps is that one has no control over where often sensitive permissions and personal content is stored. While we’re allowed a certain amount of input when it comes to downloading the app and installing it: agree to the permissions or else, we have no control over where or how all the data is stored.
We know that it’s probably in the cloud somewhere, but it could be anywhere, even on the phone itself. And each app developer has its own idea about how to handle the stuff.
That is a problem for security—not the app developers’ but ours. And it doesn’t stop at phones. Anyone know where the password for an IoT oven is located, and how securely? The answer is no and maybe not very.
Here’s a solution, though: Create your own cloud with all your own personal data in it, and then allow the smartphone apps and fitness bands to access it when it needs to pull down or write data.
The app developer should be out of the equation, some computer scientists think. The personal data is controlled by the user with an interest in its security, not the developer who may not care much.
“This is a rethinking of the web infrastructure,” Frank Wang says in a CSAIL press release. Wang is a student at MIT’s CSAIL and is one of the concept’s planners. “Maybe it’s better that one person manages all their data. There’s one type of security and not 10 types of security,” he says.
MIT calls its project Sieve.
The idea is that all of a user’s personal data is encrypted in the cloud. When an app needs to use some of the data, it simply requests it. A decryption key is then sent to the app for the relevant chunks of data. Fall out with the developer, and the user can revoke access. Keys can be re-made at any time.
It’s a simple idea that could improve security. The party who cares about the security controls it.
One slight hiccup is just how to implement the encryption. It’s not as simple as the encryption of a file, transaction, or e-mail, say. In this case each piece of data needs an attribute that only allows decryption if the requester has permissions. That’s an amusing and ironic turning of the tables.
A name and city, but not a Social Security number, or street name, could be an example of the kind of bespoke personal information delivery allowed for one app, for example. The technique is called attribute-based encryption and is not in itself a problem to implement. The trouble arises because it’s slow to encrypt and decrypt, CSAIL explains in its press release.
The solution is a kind of lumping of data “under a single attribute,” the release says.
“For instance, a doctor might be interested in data from a patient’s fitness-tracking device but probably not in the details of a single afternoon’s run. The user might choose to group fitness data by month,” it says.
All very well and good, one might think of the plan. But why would the app developers go for it?
It would be partly to differentiate themselves from others as being more security-au-fait, the researchers think. And also, the end user might decide to share certain bits of previously unobtainable, unrelated data—data that he or she now owns. Throwing the dog a bone from time to time, as it were.
This article is published as part of the IDG Contributor Network. Want to Join?