Managed Email Services for Business
Managed Email Services for Business
Fundamentally, the reason to use encryption is to protect data so that only a specific person (for example, bob@b.com) or a machine (for example, www.safeserve.com) can access it. However, until now, encryption techniques have relied on long, randomly generated keys that must be mapped to identities using digitally-signed documents, called certificates. The management of these certificates, and the need to fetch a certificate before encrypting to a person or machine, has made encryption very difficult.
Identity-Based Encryption (IBE) takes a completely new approach to the problem of encryption. IBE can use any arbitrary string as a public key, enabling data to be protected without the need for certificates. Protection is provided by a key server that controls the mapping of identities to decryption keys.
The design of an Identity-Based Encryption system was a long-standing open problem in cryptography. Safeserve now offers a service based on the first secure, practical IBE system, the Boneh-Franklin IBE Algorithm.
Identity-Based Encryption (IBE) dramatically simplifies the process of securing sensitive communications. For example, the following diagram illustrates how Alice would send a secure email to Bob using IBE:
Step 1: Alice encrypts the email using Bob’s e-mail address, “bob@b.com”, as the public key.
Step 2: When Bob receives the message, he contacts the key server. The key server contacts a directory or other external authentication source to authenticate Bob’s identity and establish any other policy elements.
Step 3: After authenticating Bob, the key server then returns his private key, with which Bob can decrypt the message. This private key can be used to decrypt all future messages received by Bob.
Note that private keys need to be generated only once, upon initial receipt of an encrypted message. All subsequent communications corresponding to the same public key can be decrypted using the same private key, even if the user is offline. Also, because the public key is generated using only Bob's email address, Bob does not need to have downloaded any software before Alice can send him a secure message.
The power of IBE is in its simplicity. By using well-known identifiers, such as email addresses, as public keys, IBE enables security policies to be encoded directly into encryption and authentication methods, eliminating the need for cumbersome certificates and Certification Authorities. See the difference yourself:
The following is a RSA public key. A certificate is required to bind this key to an identity (i.e. to state that this key belongs to bob@b.com).
Public exponent:
0x10001
Modulus: 13506641086599522334960321627880596993888147560566702752448514 38515265106048595338339402871505719094417982072821644715513736 80419703964191743046496589274256239341020864383202110372958725 76235850964311056407350150818751067659462920556368552947521350 0852879416377328533906109750544334999811150056977236890927563
n contrast, this is an IBE public key. No certificate is required because the key is the identity.
Name = bob@b.com
By eliminating the need for certificates, IBE removes the hurdles of PKI: certificate lookup, lifecycle management, Certificate Revocation Lists, and cross-certification issues. IBE's simplicity enables it to be used in ways PKI could not; IBE can be used to build security systems that are more dynamic, lightweight and scalable.
The mathematical foundation of IBE is a special type of function called a “bilinear map.” A bilinear map is a pairing that has the property:
Pair( a • X, b • Y ) = Pair( b • X, a • Y )
The operator “•” is multiplication of a point on an elliptic curve by integers. While multiplication itself (e.g., calculating a•X) is easy, the inverse operation (finding a given X and a•X) is practically impossible. Two examples of bilinear maps are the Weil Pairing and the Tate Pairing.
The IBE algorithm consists of four operations:
Setup, which initializes a key server
Encrypt, which encrypts a message for a given
user
Key Generation, which generates a private key
for a given user
Decrypt, which given a private key, decrypts a
message
To initialize an IBE security district, a key server picks an elliptic curve, a secret s and a point P on the curve using a random number generator.
Next, the public parameters, P and s•P (the product of s and P), are distributed to all users, typically via a server certificate.
The secret s can also be secret shared so that no single server compromise can compromise the system.
The sender, Alice, to encrypt a message to Bob, first hashes Bob’s identity (this might, for example, be the string “bob@b.com”) to a point on the elliptic curve IDBob. She then picks a random r and calculates a key k:
k = Pair( r • IDBob , s • P )
Alice then sends to Bob Ek[Message], the message encrypted with k. We also send him the product r • P.
Key Generation
When Bob receives the message, he may not yet have a private key. To get a private key, he authenticates to the key server.
The key server, after authenticating Bob, calculates s•IDBob and returns it to him. This value is his private key.
After receiving the message and a key, Bob can recover the key k by calculating:
k = Pair( s • IDBob , r • P )
which, because of the properties of bilinear maps, is the same as the key Alice used to encrypt the message:
k = Pair( r • IDBob , s • P )
With k, Bob can decrypt the message. As Bob is the only person who knows his private key, s • IDBob, no one else can calculate k.
For additional resources about the math behind IBE, click here
