Cryptography Reference
In-Depth Information
need for a public key or, in slightly different terms, that the public key of a user
would be her identity string (or easily derivable from this identity by, for example,
applying a hash function to it). This is precisely the basic definition of IBC.
It is readily apparent that such a framework has enormous practical advantages
in comparison with the usual certificate-based public-key encryption. In the first
place, any user could send encrypted messages to anyone without having to worry
about the public key, so that the only additional requirement for the system to work
properly would be that the receiver knows her private key. It is then clear that a crucial
requirement for the establishment of IBC is that these private keys must be computed
from the public identity in a way that makes it infeasible to compute them without
additional trapdoor information. This is in some sense analogous to what happens to
the relation between public and private keys in standard public-key cryptography but
there is, nonetheless, an essential difference. When computing a public key/private
key pair in standard public-key cryptography, the user (or the trusted party that
computes the key) may start by computing some trapdoor information that, in turn,
may be used to generate the public key, i.e., the private key is generated first and
then the public key is computed from it. In the case of IBC, this method is not viable
because the public key is already given by the public identity. Thus the private key
must be obtained from the given public key and, if keys were generated by the users
themselves, then each user would know how to obtain her private key from her public
key and hence, using the same method, would also be able to compute the private key
of any other user from that user's public identity. The system cannot take advantage
of any user-specific information other than the public identity and hence the private
key must be computed based on global trapdoor information which is common to all
users of the system. As a consequence, the owner of this trapdoor information must
be a trusted authority able to compute and distribute the keys of all users in a secure
way. This owner is usually called the
Private Key Generator
(PKG) or also the
Key
Generation Center
.
The nature of the PKG makes the trust issue even more crucial than in the case
of standard public-key cryptography because all the security of the system relies on
this single central authority that must be trusted by all users. Moreover, the PKG
requires an even higher level of trust than a CA since users have to trust its ability
to keep the global trapdoor information secret and to provide each of them with a
private key after verifying their identity. In addition, in contrast with a CA which
only issues certificates of public keys generated by users, the PKG must be trusted
not to make use of the private keys it generates—which would allow it to decrypt all
the messages sent by users—and not to deliver private keys to users different from
the legitimate one. Thus IBC implies a strong form of key escrow and to alleviate
the security risk that this entails, techniques from threshold cryptography have been
proposed to allow the distribution of the master key among several “partial” PKGs,
in such a way that a specified minimum number of them must cooperate in order to
derive a private key.
Apart from trust issues, there are other aspects that have to be carefully considered
in order to design a useful and secure IBE scheme. One of them is that a reliable
method to associate an identity string with every user is needed. Another is the issue
