Monday, April 27, 2009
More thoughts on Identity Based Encryption
Awhile back, I blogged on Identity Based Encryption and wanted to share additional thoughts...
Next week is the start of what I predict will be one of the most meaningful conferences to occur on the planet. The European Identity Conference will feature the likes of Pat Patterson, Jackson Shaw, Kim Cameron, Luther Martin, David Kearns and other thought leaders all under one roof talking about all things identity related. Anyway, I am sitting here thinking about identity and this reminded me of identity-based encryption.
Identity Based Encryption really isn't about encryption but is more about key management. Encryption is an easier topic on many levels than key management and I believe that IBE attempts to sweep the difficulties associated under the rug. Trying to use identity as the foundation is fraught with problems, because no one has a really good solution to verifying identity in electronic applications, whether on the net or in the physical world. Without a good solution to identity, these IBE schemes fall on their face once you stress the identities they rely on.
Most of the IBE systems discussed in the wild lack the technical thought leadership necessary and simply devolve to "trust the provider", which doesn't scale and doesn't provide real security when you really care about it. The provider endeavors to to establish identity over the network, and then acts as a trusted third party, holding the encryption keys for everyone. Relying on a trusted third party has many known weaknesses.
The problem is that you have to have a way of generating and managing those keys, and that turns out to be hard, because the scheme is only as good as the protection you have on your private key. There are a number of methods for doing this.
ID based encryption attempts to simplify this key management problem by proposing special algorithms that construct private keys from a known public piece of information: say an email address. To do this in a way that still makes it hard to figure out the private side, you need to have a trusted entity who constructs the private key based on some other secret they know. So, to establish your communications with someone who knows your email address. you go to the trusted provider and ask for the private key to be generated. The person you want to communicate with knows what provider you use, and gets a master public key from that provider.
Now, the person you want to send to can then generate the public side from your ID without knowing anything except some master key information from the provider; the key is never transmitted direction.
In other words, it looks like this: Alice wants to send email to Bob that's encrypted. They both trust a provider, Tom.
Alice sends a request to Tom with her email address "alice@example.com", and gets back a private key P. There is a corresponding public key p, but Tom doesn't send that to anyone.
Bob sends a request to Tom and gets Tom's master public key m.
Alice encrypts her message "x" with her private key, giving {"x"}P. (That notation is just "message "x" "wrapped" or encryption with key P.) Alice then sends that message to Bob.
Bob uses his knowledge of Alice's email address and Tom's master key m, and computes. p=f("alice@example.com", m). Now he applies the decryption decrypt({"x")P, p) and poof, out comes Alice's message.
The thing about these schemes is that it simplifies some key management issues, but only somewhat. You still need to generate the keys, and what's worse, you have to really trust Tom, because he knows everything: he can generate your private key, and encrypt with it, making any message look like it came from you. What this means is that it creates an inherent key escrow scheme; your private key can be found out.
Most of the IBE systems I've seen any technical detail about really devolve to "trust the provider", which doesn't scale and doesn't provide real security when you really care about it. The provider endeavors to to establish identity over the network, and then acts as a trusted third party, holding the encryption keys for everyone. Relying on a trusted third party has many known weaknesses.
Modern cryptography is all about searching for ways to not have to rely on the third party. Web of trust is one approach, the main drawback is that it leaves key management to the end users. The solution is not to make key management more expensive but to reduce the process and practices around it.
Traditional PKI approaches rely on certificate issuers where there is clarity on who the certificate issuers are and are known trusted third parties by all. A few years ago, one of the major issues that all the browsers trusted went bust and was bought out of bankruptcy by a player who wasn't obviously trustworthy, making it clear that the weakness in that scheme is at the root of the certificate chains.
| | View blog reactionsNext week is the start of what I predict will be one of the most meaningful conferences to occur on the planet. The European Identity Conference will feature the likes of Pat Patterson, Jackson Shaw, Kim Cameron, Luther Martin, David Kearns and other thought leaders all under one roof talking about all things identity related. Anyway, I am sitting here thinking about identity and this reminded me of identity-based encryption.
Identity Based Encryption really isn't about encryption but is more about key management. Encryption is an easier topic on many levels than key management and I believe that IBE attempts to sweep the difficulties associated under the rug. Trying to use identity as the foundation is fraught with problems, because no one has a really good solution to verifying identity in electronic applications, whether on the net or in the physical world. Without a good solution to identity, these IBE schemes fall on their face once you stress the identities they rely on.
Most of the IBE systems discussed in the wild lack the technical thought leadership necessary and simply devolve to "trust the provider", which doesn't scale and doesn't provide real security when you really care about it. The provider endeavors to to establish identity over the network, and then acts as a trusted third party, holding the encryption keys for everyone. Relying on a trusted third party has many known weaknesses.
The problem is that you have to have a way of generating and managing those keys, and that turns out to be hard, because the scheme is only as good as the protection you have on your private key. There are a number of methods for doing this.
ID based encryption attempts to simplify this key management problem by proposing special algorithms that construct private keys from a known public piece of information: say an email address. To do this in a way that still makes it hard to figure out the private side, you need to have a trusted entity who constructs the private key based on some other secret they know. So, to establish your communications with someone who knows your email address. you go to the trusted provider and ask for the private key to be generated. The person you want to communicate with knows what provider you use, and gets a master public key from that provider.
Now, the person you want to send to can then generate the public side from your ID without knowing anything except some master key information from the provider; the key is never transmitted direction.
In other words, it looks like this: Alice wants to send email to Bob that's encrypted. They both trust a provider, Tom.
The thing about these schemes is that it simplifies some key management issues, but only somewhat. You still need to generate the keys, and what's worse, you have to really trust Tom, because he knows everything: he can generate your private key, and encrypt with it, making any message look like it came from you. What this means is that it creates an inherent key escrow scheme; your private key can be found out.
Most of the IBE systems I've seen any technical detail about really devolve to "trust the provider", which doesn't scale and doesn't provide real security when you really care about it. The provider endeavors to to establish identity over the network, and then acts as a trusted third party, holding the encryption keys for everyone. Relying on a trusted third party has many known weaknesses.
Modern cryptography is all about searching for ways to not have to rely on the third party. Web of trust is one approach, the main drawback is that it leaves key management to the end users. The solution is not to make key management more expensive but to reduce the process and practices around it.
Traditional PKI approaches rely on certificate issuers where there is clarity on who the certificate issuers are and are known trusted third parties by all. A few years ago, one of the major issues that all the browsers trusted went bust and was bought out of bankruptcy by a player who wasn't obviously trustworthy, making it clear that the weakness in that scheme is at the root of the certificate chains.
