Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Why decentralized encryption key management for mobile is dangerous

public://pictures/kazarian.jpg
Jason Paul Kazarian Principal Architect, Micro Focus
 

Psst! Hey, buddy! It’s 10 PM. Do you know where your encryption keys are?

If my paraphrase of Mel Epstein’s 1967 public service announcement has a familiar ring to it, that might be because you remember the original PSA, which ran for almost 30 years. But you might also be thinking about recent government behavior that should have you thinking about the importance of encryption in general, and the use of key control and escrow in particular.

Decentralized key management, where users have all of the control, is fraught with risks. There's a better way, and the recent incident in the city of San Bernardino, California, offers a good illustration as to why you need to retake control from your end users. 

Learning from San Bernardino

Last December, after police shot and killed a couple in San Bernardino in the wake of a mass shooting, the FBI obtained an Apple iPhone 5C that belonged to one of the shooters, Syed Farook, a city employee. But the device had been locked using the the data encryption built into iOS. In February, the FBI obtained a judgment against Apple to provide “reasonable technical assistance” to recover the phone’s data.

Apple refused, a court ruled in Apple’s favor, and the FBI withdrew the request in this hotly contested case, saying it had found a way to obtain the data for $1 million. Or $1.3 million. Or perhaps both. But if the encryption on this employee's phone had been centrally managed, the city would have had access to the key to unencrypt the phone, and the problem could have been solved quickly.

The San Bernardino shooting case drew national attention to government attempts to circumvent encryption. But think about this: What would you do if, for some reason or other, your enterprise could not access important data because the key belonged to an employee who was out sick? Or worse? 

Leaving key management to users is a bad idea

Having end users responsible for their own security infrastructure, such as keys and certificates, has been problematic for quite some time. Pretty Good Privacy (PGP), also called a web of trust, was initially built on a decentralized model, primarily because PGP’s initial mission was to protect emails sent between parties from being intercepted and read.

In PGP, each user is responsible for generating his own public and private keys. But decentralization didn’t stop there: Users were responsible for certifying to each other that people were who they said they were. For example, if Alice believes a PGP public key really came from Bob, she could sign this key and pass it on to Chris. Afterwards, Chris would trust the same public key as coming from Bob. PGP was built on this transitive trust model.

That, as you might imagine, is a criminal’s playground. Chris trusts Bob because Alice says it’s okay, but when does the transitive model break down? It is possible that within a decentralized chain of trust, one link could create a key pair and sign the public key as belonging to an earlier link. This opens up the door to man in the middle attacks, especially when PGP is the only communication mechanism among links in the chain.

A better way: Why you need a central authority

You can solve the problems inherent with a web of trust by moving the job of signing (trusting) to a central authority. Enterprises do this routinely with a network of X.509 certificate authorities, which can definitively answer the question as to whether or not Bob’s public key really came from Bob. And this model works for trust: If you’ve ever gotten a browser message saying something along the lines of “Don’t visit this site! It’s not secure!” you’ve seen an example of the centralized trust model at work.

Where does the certificate authority model break down? For trust, it doesn’t. But centralized trust does not mean keys are also centralized. And one thing worse than a web of trust is a web of keys, where every user is responsible for generating and maintaining a pair (or two, or three) of encryption keys.

Giving end users this responsibility presents security risks in many different scenarios. For example, consider rights management. Suppose Bob shares some data with Alice, Chris, and Dave and other data only with Alice and Chris. Bob needs at least two key pairs: One he shared with all three, and one he shares with just the first two. Thus, Dave can access some of Bob’s data, but not all of it.

If Bob has about a dozen different distribution lists that each have different access rights, Bob must create and store about a dozen key pairs. And poor Bob needs to remember which public key to associate with which group. If he doesn't, at best, some people won’t have access to the needed data, and at worst, others will have access to data improperly.

And who is responsible for distributing these keys? Bob is, of course. But what about Alice, who is on two of Bob’s distribution lists, one with Dave and one without? And what if Alice accidentally shares the wrong key with Dave? Will Bob ever know? According to a state of California report, 17 percent of data breaches are due to accidents and inadvertent exposure.

A pound of prevention: Move to centralized key escrow and key management

While the use of a central authority, or centralized trust, has greatly helped organizations grow more trust into an expanding Internet, the continued use of the web of keys formed by decentralized key management is just causing more headaches. The problem is not just the headache associated with unauthorized distribution of keys, but also with getting a key in the custody of an end user to an authorized user, especially in cases where the key owner is absent for some reason. 

The solution is to use centralized key escrow and key management techniques. Once you abandon decentralized key management, you'll never be locked out of your own data again.

Keep learning

Read more articles about: SecurityData Security