Search This Blog

Monday, October 16, 2006

Identity Based Encryption (IBE)

Lazy days are just perfect for me to catch up with reading. This Saturday, as I was browsing through the Internet reading up on new (at least for me) trends and technologies, I came across a recent I-D on a scheme called Identity Based Encryption (IBE) 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: and

In the current mechanism of PKI based security, the following happens:

  1. UserA contacts a key server to obtain the certificate of userB. Let us assume that the keyserver for vzw domain resides at
  2. UserA then needs to compare the certificate with a revocation list, to ensure that the certificate has not been revoked for some reason
  3. UserA should also check whether this key has been signed as authentic from some central authority (say, like Verisign)
  4. UserA then extracts userB's public key from the certificate, encodes the message, and sends it off
  5. UserB, assuming that it has its private key is now able to decrypt the message
  6. (If User B did not have his private key, or it needed to be refreshed, it would contact its key server at securely to obtain it)
There are several issues with this approach:
  1. The process of certificate management and verification is expensive for userA
  2. 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
  3. 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)
With IBE, steps 1-4 are greatly reduced. Here is what happens with IBE:
  1. wants to communicate securely with First, userA contacts to obtain what is know as a Master Private key, for the 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)
  2. Next user A uses the identity string 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
  3. userB now contacts its key server at and performs a security exchange proving it is the rightful owner of the identity. Once satisfied, provides userB with its private key which userB can then use to decrypt
  4. Once userB has received its private key, it does not need to contact'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.
This has some very interesting ramifications:
  1. userA can now send secure emails to userB without the problems of first getting its public key
  2. The computational power requirement for userA reduces (think cell phones and battery consumption)
  3. userB could choose to setup its private key after receiving a secure message from userA.
  4. 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.
  5. 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)
Consider some use-cases:
  1. Assume that corporation has deployed this scheme, then any emails encrypted with “” can generate a private key that applies to all avaya employees. Similarly, an Avaya employee could send an ad-hoc encrypted email only to “” 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.
Finally, since the mathematical foundation allows for association with arbitrary strings, each domain can set its own key generation rules. This brings us to my last interesting read, “Fuzzy IBE”. In this approach, the authors extend the scheme to allow for ‘fuzziness of accuracy’. In this approach, when UserB tries to communicate with vzw’s key server to provide he is indeed, instead of key exactness, the server and the client (server=VZW key server, client=user B) negotiate a set of attributes which defines B. The server could choose to grant userB it’s private key even if not all attributes are exactly matching. The degree of error tolerance, however is key and the paper discusses algorithms to securely prove its veracity given a particular tolerance. Why is this useful ? Consider for example, the new phones being launched with voice recognition scan or biometric scans. Such idenity proofs are a combination of multiple attributes, and there is no guarantee that are all the same all the time. For example, an iris recognition could go astray, if you just got punched in your eye by the boyfriend of a girl you were trying to warm up to. Or, your voice recognition identity may go astray if you happened to be partying all night before, screaming ‘Who Let The Dogs Out’ So all in all, IBE offers a very convenient approach to standard certificate mechanisms that hopefully will really help in domain based security systems by greatly reducing existing pains that plague the certificate community. In addition, being able to map a URI (identity) to an encryption mechanism should greatly help its deployment in the VoIP space as well.


  1. Once the recipient of an IBE email receives a key they no longer have to get the key for future messages. What happens if they use a different computer? What happens if they log on to webmail on a public computer in an Internet cafe? Is their private key downloaded there for future users of that machine to potentially exploit? What if someone can steal the private key from the recipients machine - since authentication only happens on the first email they could basically read any email after that point if they have the key?

  2. IBE is a mechanism to map an arbitrary string to a private Key. Storage of the Private Key is the responsibility of the user, just as it is true with PKI. Also, IBE allows you to attach any validty to it as well, so one could configure the master server with a timebased rule, that invalidates the private key aftera while. Finally, if you go to another computer, and don't have access to your private key, you can re-exchange credentials with the master server.

  3. In 2002, an inventor, Patrick Zuili is the first one to have beeb able to integrate the biometric identity into IBE Identity-Based Encryption.
    This an extremely interesting advantage and very valuable aspect of this patent.

    United States Patent 7,083,090
    Zuili August 1, 2006
    19. The method of claim 18, wherein the biometric input is a fingerprint.

    20. The method of claim 1, wherein information exchange subsequent to the transaction request are encrypted.

    21. The method of claim 20, wherein the encryption is based on public-key cryptography.

    22. The method of claim 20, wherein the encryption is based on identity-based encryption (IBE) cryptography.