here. The premise and applicability of this technology seemed pretty interesting, so I read more here, here and other places. This technology is currently being pioneered by a relatively new company, called Voltage Security.
I don't claim to understand complex mathematics, so I am going to restrict my comments on its applicability. Simply put, IBE is not a complete replacement of existing asymmetrical cryptographic algorithms. It allows a mechanism where an arbitrary string could be used by the 'sender' as a means to encrypt a message. Based on that identity string, the receiver can obtain a private key to decrypt it, as long as the receiver can satisfactorily prove to some 'Key Server' that it is the rightful owner of that 'arbitary identity' string. This eliminates the need for certificate exchanges before a communication takes place in traditional PKI schemes.
This makes more sense when we apply a deployment model to it. Consider for example, two parties: firstname.lastname@example.org and email@example.com
In the current mechanism of PKI based security, the following happens:
- UserA contacts a key server to obtain the certificate of userB. Let us assume that the keyserver for vzw domain resides at vzw.com.
- UserA then needs to compare the certificate with a revocation list, to ensure that the certificate has not been revoked for some reason
- UserA should also check whether this key has been signed as authentic from some central authority (say, like Verisign)
- UserA then extracts userB's public key from the certificate, encodes the message, and sends it off
- UserB, assuming that it has its private key is now able to decrypt the message
- (If User B did not have his private key, or it needed to be refreshed, it would contact its key server at vzw.com securely to obtain it)
- The process of certificate management and verification is expensive for userA
- For this to work, it is necessary for UserB to have a public certificate created in the first place, or userA cannot even contact UserB
- The mechanism of directly distributing public keys (the long string of digits you usually see in many mails and sites that say 'My Public RSA Key is below:') binds it statically to the associated identity (this will be clear when I talk about the advantages of IBE)
- firstname.lastname@example.org wants to communicate securely with email@example.com. First, userA contacts vzw.com to obtain what is know as a Master Private key, for the vzw.com domain (remember, we are assuming a deployment model where each master domain manages its own security, and hence, we assume each primary domain will have its own unique master key. Nothing stops multiple domains to use some central master key server, however)
- Next user A uses the identity string firstname.lastname@example.org as the public key of userb and encrypts the message along with the received master key. What this means is that userB receives an encrypted s/mime message with the From, To and other routing headers intact, but a garbled text body
- userB now contacts its key server at vzw.com and performs a security exchange proving it is the rightful owner of the identity. Once satisfied, vzw.com provides userB with its private key which userB can then use to decrypt
- Once userB has received its private key, it does not need to contact vzw.com's key server each time - it can continue using the same key henceforth, based on the expiry and policies as set by verizon's key server (this is the same as PKI). In other words, IBE essentially provides a mapping between a abitrary string and the PKI private key that will eventually be used to decrypt the message.
- userA can now send secure emails to userB without the problems of first getting its public key
- The computational power requirement for userA reduces (think cell phones and battery consumption)
- userB could choose to setup its private key after receiving a secure message from userA.
- Since the outgoing encryption is based on a string, ad-hoc policies are very simple to implement without the cost of re-invoking/revoking certifcates.
- Since keys are generated on demand, the key server is essentially stateless, which lends to better scaling for the key server (thanks to a person in the 'know' who read and reminded me of this point)
- Assume that avaya.com corporation has deployed this scheme, then any emails encrypted with “avaya.com” can generate a private key that applies to all avaya employees. Similarly, an Avaya employee could send an ad-hoc encrypted email only to “sip.avaya.com” for all it’s SIP development list organization. These strings and relation to an appropriate private key is therefore dynamic. You don’t need to pre-create dozens of certificates for such relationships. If a key server for a domain does not want to honor that identity string attribute, it can reject it.