The Identity Based Encryption and Aggregate Signature from
Bilinear Map
Yu-Li Chou <ychou@cs.odu.edu>
Advisor: Dr. Abdel-Wahab, Hussein
Abstract
This paper is talking about two applications from Bilinear Map: the Identity Based
Encryption and Aggregate Signature. The Identity Based Encryption (IBE) system is a
system that uses a user identity (ID) as a public key. The scheme is based on Bilinear
Maps between groups and assumes a variant of the computational Diffie-Hellman
problem. We give definitions for secure Identity Based Encryption schemes and as well
as several applications for such systems.
We also introduce the concept of an Aggregate Signature and give several
applications for Aggregate Signatures in this paper. An Aggregate Signature scheme is a
digital signature that supports aggregation; given n signatures on n distinct messages
from n distinct users, it is possible to aggregate all these signatures into a single short
signature. This single signature (and the n original messages) will convince the verifier
that the n users did sign the n original messages. The efficient Aggregate Signature is also
based on Bilinear Map. Aggregate Signatures are useful for reducing the size of
certificate chains (by aggregating all signatures in the chain) and for reducing message
size in secure routing protocols.
We propose both ideas and applications for such systems in this paper. There is also
a simple program demonstration and explanation to support such systems.
Basic theory of Bilinear Map
The security of our system is based on a natural analogue of the computational
Diffie-Hellman assumption. First let us take a look at the basic theory of Bilinear Map.
Let G1 and G2 be two groups of order q for some large prime q. Our IBE system makes
use of a bilinear map ^e: G1 × G1
G2 between these two groups. The map must satisfy
the following properties:
1. Bilinear: We say that a map ^e: G1 × G1
G2 is bilinear if ^e(aP; bQ) = ^e(P;Q)ab
for all P, Q  G1 and all a, bZ.
2. Non-degenerate: The map does not send all pairs in G1 × G1 to the identity in G2.
Observe that since G1 and G2 are groups of prime order; this implies that if P is a
generator of G1, then ^e(P; P) is a generator of G2.
3. Computable: There is an efficient algorithm to compute ^e(P;Q) for any P,QG1.
A bilinear map satisfying the three properties above is said to be an admissible bilinear
map.
The existence of the bilinear map ^e: G1 × G1
G2 as above has two direct
implications to these groups.
Decision Diffie-Hellman is easy: The Decision Diffie-Hellman problem (DDH). Given
aP, bP, cP  G1. If we want to decide whether cP = abP, we can easily determine by
checking ^e (P, cP) = ^e (aP, bP).
Computational Diffie-Hellman is hard: The Computational Diffie-Hellman problem
(CDH). Given P, aP, bP  G1, if we want to compute abP  G1, it is assume to be hard.
Since the Decision Diffie-Hellman problem (DDH) in G1 is easy, we cannot use
DDH to build our cryptosystems. Instead, the security of our IBE system is based on a
variant of the Computational Diffie-Hellman assumption (CDH).
Introduction
After understanding the basic idea of Bilinear Map, the topic of this paper is about
the applications that derive from it: Identity Based Encryption and Aggregate Signature.
In 1984 Dr. Shamir asked for a public key encryption scheme in which the public
key can be an arbitrary string. His original motivation was to simplify the certificate
management in e-mail systems. Such a system requires 4 steps: (1) setup generates
system parameters and a master key, (2) extract uses the master key to generate the
private key corresponding to an arbitrary public key string which can be any string (ID),
(3) encrypt encrypts messages using the public key (ID), and (4) decrypt decrypts the
message using the private key.
In traditional security schemes, one of the popular approaches is public key infrastructure (PKI), where individual users generate their own key pairs. They keep their
private keys themselves and upload their public keys to a public key server. Everyone can
get the public key from the key server and use it to encrypt the message for other
purposes. Suppose Alice wishes to send Bob an encrypted message. She must contact the
correct key server (or otherwise obtain Bob’s public key), encrypt the message, and send
it to him. If Bob had not generate a key pair for him, uploaded it to a key server, or if
Alice cannot find Bob’s public key, she will not be able to encrypt the message and send
it to Bob.
The advantage of Identity Based Encryption (IBE) system is that users can choose
any arbitrary string as their public key. The string can be any string, an e-mail address,
network IP, or telephone number. For example, Bob can use his e-mail address
(Bob@cs.odu.edu) as his public key. He will get his private key from Key Generate
Association corresponding to his public key and also prove himself as Bob to the
association. When Alice sends mail to Bob at Bob@cs.odu.edu; she simply encrypts her
message using the public key string “Bob@cs.odu.edu”. There is no need for Alice to
obtain Bob's public key from the key server as long as Bob announces his public key as
his e-mail address. When Bob receives the encrypted mail; he contacts a third party,
which we call the Private Key Generator (PKG). Bob authenticates himself to the PKG in
the same way he would authenticate himself to a Certificate Authorities and obtains his
private key from the PKG. Bob can then decrypt the message and read his e-mail. Note
that unlike the existing secure e-mail infrastructure, Alice can send encrypted mail to Bob
even if Bob has not yet setup his public key certificate in advance. Also note that key
escrow is inherent in Identity Based e-mail systems; the PKG knows Bob's private key.
We discuss key revocation, as well as several new applications for IBE schemes in the
next section.
While using Bilinear Map to build a secure system such as IBE, we also propose
another application using Bilinear Map; the aggregate signature. Many real world
applications involve signatures on many different messages generated by many different
users. In a Public Key Infrastructure of n depth, each user is given a chain of certificates.
The chain contains n signatures by n Certificate Authorities on n distinct certificates.
An aggregate signature scheme enables us to achieve compression of signatures.
Suppose there are n users; each user has a public-private key pair. User ui signs message
Mi to obtain a signature Si. Then there is a public aggregation algorithm that takes input of
all signatures S1…Si and outputs a short compression signature S. Anyone can aggregate
the n signatures. Moreover, the aggregation can be incremental. The signature S1, S2 can
be aggregated into S12 and further aggregated with S3 to obtain S123. There is also an
algorithm that verifies the compressed signature. Thus, an aggregate signature provides
non-repudiation at once on many different messages by many users.
After giving some simple introduction of Identity Based Encryption and Aggregate
Signature; we can look at the details of them and give more definitions.
Scheme of Identity Based Encryption
Here explains the scenario of IBE:
Step 1: Alice wants to send an e-mail to Bob. She encrypts the email using
Bob’s e-mail address, “Bob@cs.odu.edu”, as the public key.
Step 2: When Bob receives the message, if he wants to read the e-mail, he has
to contact the key server. The key server contacts a directory or domain server
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. However, we have to notice that
in this scenario the IBE system provides key escrow since the PKG knows
Bob's private key.
This IBE scheme consists of four algorithms:
(1) Setup generates global system parameters and a master-key (ID).
(2) Extract uses the master-key to generate the private key corresponding to an arbitrary
public key string ID.
(3) Encrypt encrypts messages using the public key ID, and
(4) Decrypt decrypts messages using the corresponding private key.
Stages in Identity Based Encryption System
Here we are to explain the details of IBE system we describe by the following:
Setup: 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.
Encrypt: The sender, Alice, to encrypt a message to Bob, first hashes Bob’s identity
(this might, for example, be the string “Bob@cs.odu.edu”) 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. The PKG 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.
Decrypt: 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.
Advantages of Identity Based Encryption system
The basic idea of Shamir is to simplify the e-mail encryption system that is different
from the traditional system we are using right now. We will discuss these two ways of
encryption and the advantages of Identity Based Encryption.
The following is a RSA public key. A certificate is required to bind this key to an
identity.
Public exponent:
0x10001
Modulus:
13506641086599522334960321627880596993888147560566702752448514
38515265106048595338339402871505719094417982072821644715513736
80419703964191743046496589274256239341020864383202110372958725
76235850964311056407350150818751067659462920556368552947521350
0852879416377328533906109750544334999811150056977236890927563
In contrast, this is an IBE public key. No certificate is required because the key is the
identity. Public Key = “Bob@cs.odu.edu”. As we can see, the public key in IBE system
is more flexible and easier to setup and understand.
Applications for Identity-Based Encryption
The original motivation for Identity Based Encryption is to help the deployment of a
public key infrastructure. More generally, IBE can simplify systems that manage a large
number of public keys. Rather than storing a big database of public keys, the system can
either derive these public keys from usernames, or simply use the integers {1,….,n} as
distinct public keys. We discuss several applications below.
Revocation of Public Keys
One of the applications in the IBE system is all users can specify an expiration date.
In an IBE system key expiration can be done by having Alice encrypt e-mail sent to Bob
using the public key: Bob@cs.odu.edu || current-year. In doing so Bob can use his
private key during the current year only. Once a year, Bob needs to obtain a new private
key from the PKG. Hence, we get the effect of annual private key expiration. Unlike the
existing public key infrastructure, Alice does not need to obtain a new certificate from
Bob every time Bob refreshes his certificate.
Furthermore, anyone could encrypt e-mail for Bob by using Bob@cs.odu.edu ||
current-date. This will force Bob to obtain a new private key every day. With this
approach key revocation is quite simple; when Bob leaves the company and his key needs
to be revoked, the corporate PKG is instructed to stop issuing private keys for Bob's
e-mail address. Unlike the existing public key infrastructure, the public key usually
remains valid for one year. If Bob leaves this company within a year, he still has the key
to decrypt any message sent to him. In this new approach, we don’t have to worry about
the key management. It also enables Alice to send messages into the future; Bob will only
be able to decrypt the e-mail on the date specified by Alice.
A simple extension to the discussion above enables us to manage all users using the
IBE system. Suppose Alice encrypts mail to Bob using the public key “Bob@cs.odu.edu
|| current-year || clearance = secret”. Then Bob will only be able to read the e-mail if on
the specified date he has secret clearance. Consequently, it is easy to grant and revoke
user credentials using the PKG.
Delegation of Decryption Keys
Another application for the IBE system is delegation of decryption capabilities.
There are two example applications. In both applications, the user Bob plays the role of
the PKG. Bob runs the setup algorithm to generate his own IBE system parameters
“params” and his own master-key. Here we view params as Bob's public key. Bob
obtains a certificate from a CA for his public key params. When Alice wishes to send
mail to Bob, she first obtains Bob's public key params from Bob's public key certificate.
Note that Bob is the only one who knows his master-key and hence there is no
key-escrow with this setup.
1. Delegation to a laptop. Suppose Alice encrypts mail to Bob using the current
date as the IBE encryption key. Since Bob has the master-key, he can extract the private
key corresponding to this IBE encryption key and then decrypt the message. Now,
suppose Bob goes on a trip for seven days. Normally, Bob would put his private key on
his laptop. If the laptop is stolen, the private key is compromised. When using the IBE
system, Bob could simply install on his laptop the seven private keys corresponding to
the seven days of the trip. If the laptop is stolen, only the private keys for those seven
days are compromised. The master-key is unharmed.
2. Delegation of duties. Suppose Alice encrypts mail to Bob using the subject line
as the IBE encryption key. Bob can decrypt mail using his master-key. Now, suppose Bob
has several assistants, each responsible for a different task (e.g. one is `purchasing',
another is `human-resources', etc.). Bob gives one private key to each of his assistants
corresponding to the assistant's responsibility. Each assistant can then decrypt messages
whose subject line falls within its responsibilities, but it cannot decrypt messages
intended for other assistants. Note that Alice only obtains a single public key from Bob
(params) and she uses that public key to send mail with any subject line of her choice.
The mail can only be read by the assistant responsible for that subject.
Above all the application uses IBE Security System, which makes public key
infrastructure more simple to use and flexible for security. The biggest drawback of PKI,
aside from simply getting people to use it, is the generating and distributing public keys.
Aggregate Signatures
Now we are going to introduce another application based on the Bilinear Map; the
Aggregate Signatures. We define Aggregate Signatures and describe an aggregate
signature scheme based on Computational Diffie-Hellman assumption.
Consider a set of N users. Each of them has a signing key pair (PK, SK). We wish to
aggregate the signatures of some subset. Each user ni produces a signature σi on a
message M of his choice. These signatures are then combined into a single aggregate σ by
an aggregate party. The party, who can be different from and un-trusted by the users in
the subset, has access to the users’ public keys, to the messages, and to the signatures on
them, but not to any private keys. The result of this aggregation is an aggregate signature
σ whose length is the same as that of any individual signatures. This aggregate has the
property that a verifier given σ along with the identities of the parties involved and their
respective messages is convinced that each user signed his message.
The scheme comprises five algorithms: Key Generation, Sign, Verify, Aggregate,
and Aggregate Verify. The first three are as in ordinary signature schemes (or in IBE
systems); the last two provide the aggregation capability.
Key Generation: To generate the user’s private key is same as the IBE system’s key
generation step. Suppose the user’s secret key is x.
Signing: For a particular user, given the secret key x and a message M, compute H;
then we will get signature σ.
Verification: Given user's public key v, a message M, and a signature σ, compute to
see if it holds.
Aggregation: For the aggregating subset of users N, each user n provides a signature
k
σ on message Mi. The messages Mi must all be distinct. Compute
   i
i 1
Aggregate Verification: We are given an aggregate signature σ for an aggregating
subset of users N, indexed as before, and are given the original messages Mi and public
keys vi for all users n. To verify the aggregate signature σ,
1. Ensure that the messages Mi are all distinct, and reject otherwise; and
2. Compute and accept if e( g1 ,  )  k e(vi , hi ) holds.
i 1
Note that aggregation can be done incrementally.
Advantages of Aggregate Signatures
The basic idea of Aggregate Signatures is also to simplify the procedure of verifying
a mount of signatures. Such as in a large company or school, it is easy to use and
convenient. In a traditional signature scheme, if we have lots of signatures that need to be
verified, we have to verify them one by one. The process takes time and disk space to
store these signatures. The Aggregate Signature provides an efficient way to compress
these signatures into one. But there still remain problems to be solved. For example, if the
verification proves wrong, it can be only said that those signatures are invalid. You can
not find which one is invalid or which document has been modified. These will remain an
open problem for people to solve.
Conclusions
In this paper, we explain the ideas of Bilinear Map and two of its applications. First
we introduce Identity Based Encryption System using Bilinear Maps that only require a
gap Diffie-Hellman group (i.e., DDH easy, but CDH hard). Compare to the traditional
RSA system we are using now, it simplifies the process of encryption and key generation.
It also has other applications such as revocation and delegation of keys. We also prove its
security and techniques.
We also introduce the concept of Aggregate Signatures based on IBE system, which
also constructed an efficient aggregate signature scheme based on Bilinear Maps. Key
generation, aggregation, and verification require no interaction. We give several
applications for aggregate signatures. For example, they can be used to reduce the size of
certificate chains and reduce communication bandwidth in protocols.
However, there remains an open problem that the chosen cipher-text secure identity
systems only secure in a standard computation model (rather than the random model).
There are already companies that offer this system for users; there might be more
applications in the future.
Many people are working on this cryptosystem now, and inventing many new
applications such as key issue, more strong secure system, authentication, and trust
authorities and certification. In the future, the demand of more secure systems will
increase. People wish to use easier to learn, but stronger applications, to protect their
computer. Maybe one day there will be an application which integrates all these
applications.
APPENDIX
Identity Based Encryption and Aggregate Signature from Bilinear Map
Program Explanation
Abstract
This appendix is trying to explain the process of Identity Based Encryption system and
Aggregate Signature. We will propose two scenarios to describe how it works. The main
actors in these scenarios are Alice and Bob.
Scenario in IBE system: Bob is secretly fall in love with Alice; he wants to let Alice
know what in his mind. He wants to send a message to Alice but doesn’t want somebody
get this message. Only Alice will get this message and decrypt it. We will show the steps
here in IBE system.
Step1: Alice will generate her public and private key pair. In this case; Alice uses her
e-mail address (Alice@cs.odu.edu) as her public key.
Syntax: ibe_keygen (under UNIX command)
The program will ask the ID that user want to use and generate private key for
the user.
Step2: Bob creates the message he wants to send to Alice; encrypts it with Alice’s public
key.
Syntax: ibe_enc <filename>
The program takes the plain text file and produces the corresponding cipher text.
Step 3: Alice gets the message and decrypts it using her private key.
Syntax: ibe_dec <filename>
The program takes the cipher text and decrypts it. The original message will
output to the screen.
These three steps are most general steps that using IBE system: generate, encrypt and
decrypt.
Scenario in Aggregate Signature: After few years; Alice and Bob got married. They
want to buy a house. Before this, they both have to sign the contract and send to the
salesman. The salesman will verify the contract and make sure the document did sign by
Alice and Bob. In the demonstration we will generate Alice and Bob’s key pairs in
advance.
Step 1: Both Alice and Bob signed the contract with their private key.
Syntax: aggregate <filename>
The program will ask for these two user’s private key file (In this case;
Alice_priv.txt and Bob_priv.txt), create two signatures and aggregate into one
aggregate signature. The result will output to the screen.
Step 2: After the salesman gets the signature; he will verify the aggregate signature and
the original document with Alice and Bob’s public keys.
Syntax: verify <aggregate_signature file> <original file>
The program will ask for the two public key file and verifies it. “Accept” or
“Reject” is the output for the verification.
If the original document has been modified by the third party; the verification will be
“Reject”. In this case, we change the contact and trying to verify it, the result shows
“Reject”.
These two steps are for the Aggregate Signature: aggregate and verify.