Modern 'primitive' could ease the pain of encrypting massive amounts of data
Multiple criteria for identity-based encryption
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
Researchers have devised an encryption scheme that could simplify the protection of sensitive information by allowing banks, hospitals and other organizations to lock files using keys that are based on specific attributes, such as an employee's position or geographic location.
The method, which was unveiled last week, adds to the growing body of research known as functional, or attribute-based encryption. Functional encryption is designed to solve the hassle tied to traditional public-key encryption resulting from distributing and managing thousands or millions of private keys authorized people need to decrypt protected data. If 1,000 people in an organization need to securely share their public key with their co-workers, that requires close to one million separate exchanges.
Functional encryption tries to simplify things. It allows data to be encrypted using attributes directly tied to the recipients, such as their names or email addresses, without the need for the parties to have exchanged keys ahead of time. Rather than relying on a single key that unlocks all data, functional encryption envisions a more flexible sort of system where a personal key unlocks some doors but not others.
For example, medical records for George Clooney, which in October were improperly accessed by snooping hospital employees, would be available only for people meeting multiple criteria, such as (a) a doctor, nurse or accountant who is (b) directly responsible for the actor's medical care or billing.
One hindrance to functional encryption is a phenomenon known as collusion, which allows attackers to gain unauthorized access by combining the attributes of multiple individuals, for example, an unrelated doctor and the accountant handling billing.
Researchers Amit Sahai from UCLA, Brent Waters of SRI International and Jonathan Katz of the University of Maryland, have surmounted, to some degree, this shortcoming. In a research paper (PDF), released at the Eurocrypt 2008 conference, they describe a new cryptographically strong "primitive" that advances functional encryption by allowing the encryption of database results based on multiple fields. A primitive is a building block used to put together an encryption system.
While the functional encryption holds out promise, don't expect it to stanch the steady stream of data breaches that have flowed out of the medical, financial and government sectors over the past few years. Functional encryption, which is related to IBE, or identity-based encryption, is saddled with administrative burdens in much the way traditional systems are.
"IBE-based systems can make it easy to assign credentials, but there's still a central server that sets the policy on these things," said Nate Lawson, principal at Root Labs, which helps companies design and analyze secure embedded systems and encryption. "Any kind of scheme will require very fine-grained management of access control so it will still require high overhead of management, and that's unavoidable."
Karsten Nohl, a graduate student at the University of Virginia focusing on encryption, agrees that IBE merely allows database architects to "move the bottleneck around". But in providing alternatives, IBE is a paradigm that's likely to change the way data is secured.
"It promises to solve the key distribution and management problem that has pretty much plagued every encryption scheme ever since encryption was invented and has become particularly challenging with the large scale of the internet," he said. ®
COMMENTS
George Clooney dead??
Anon, that's hilarious. That kind of administrative overhead is what keeps people from implementing this kind of fine-grained access with mechanisms available today (i.e. ACLs). No matter how strong your enforcement, you still need a person to sit there doling out credentials and assigning ACLs to the database records. This functional encryption scheme is just stronger enforcement but doesn't change the fundamental policy overhead.
Also, one point I made that wasn't in the article is that better auditing is important to resolving this issue. If staff is notified that a random user will be selected each month to have all their queries reviewed, then they will be more careful to avoid exceeding their authority. The staff that was sacked for looking up celebrity records were only found because there was a "lock" on those records. But this doesn't stop looking up boyfriends or bosses, etc. so there needs to be some random review process to protect those of us who aren't famous.
-- Nate Lawson
Not ideal when time is of the essence
"Mr George Clooney died this morning after the doctor treating him collapsed from exhaustion and another, drafted in from a different hospital due to staff shortages, was unable to access his medical records on account of administrative delays."
"It seems that the doctor had obtained the necessary paperwork, passed it to the Departmental Authoriser who, when he got back from lunch, passed it to the Senior Authoriser who, upon returning from his golfing holiday, approved it and passed it to an assistant, who faxed it to the offshore call centre that handles the hospital's IT admin. They queued, prioritised, processed and filed the request in accordance with their SLA, and then notified the doctor."
"However, by the time that all this had been completed, it seems that the unfortunate Mr Clooney had been dead for several days."
Re: Am I being dense?
True. Its kind of stupid using easily-guessed "keys" to encrypt sensitive stuff. Even if it is what I understand, names of different persons, there are finite number of combinations to be tried. On top of that, full names in English-speaking countries usually are name + 1 surname, which ends up having lots of collisions (just how many 'John Smith' can you find?) and reducing even more the probabilities. Which anyone would get by doing a simple SELECT * FROM employee.
@Dan Goodin: Thats what CA's were made for. You get *one* single Root CA, and do all the checks to verify the public key comes from the actual user. Place the signed public key on an LDAP, and the distribution problem goes away, isn't this what PKI is all about? ;)
Disclosure: My previous job involved Information Security, PKI, and other fun stuff.
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
