Actually, I'm not familiar to how identity-based and certificate-based systems work, so ,can anyone give me a detail and comprehensive answer to this question? Moreover, in what environments the identity-based systems is recommended(or needed) and why?

  • 2
    $\begingroup$ You don't need to be able to be able to obtain the public key of the recipient before you can encrypt a message to them since you can compute it. That's pretty much the only advantage over certificated based PKI and comes at the steep price of the central authority being able to decrypt everything. $\endgroup$ – CodesInChaos Jan 17 '14 at 12:15
  • $\begingroup$ @Alex You may find this article of Desmedt and Burmester interesting. It is easy to read for a beginner and discusses issues when deploying identity-based crypto in practice (compared to certificate-based systems). $\endgroup$ – DrLecter Jan 17 '14 at 15:35
  • $\begingroup$ cont. You might also find this article interesting. $\endgroup$ – DrLecter Jan 17 '14 at 15:54

Public key crypto vs. identity-based crypto made short:

In traditional public key cryptography, a user $A$ generates a private/public key pair $(sk_A,pk_A)$ and since this key pair has absolutely no indication to which indentity (user $A$) it belongs, it is necessary to certify the public key, i.e., bind the public key $pk_A$ to the user $A$'s identity. This is commonly done by lettig some trusted authority sign $pk_A$ with additional identifying information of user $A$ after user $A$ proves by some means that he really is user $A$ (the result is what is called a certificate).

Identity-based cryptography aims at letting the users public key be its identity (e.g., the email address) and so to remove the requirement for certificates. In ID based cryptography a user $A$ uses his identity (e.g., his email address) as public key. Now, however, since this information could be used by anybody as an identity it is clear, that there needs to be some other entity involved in generating the respective private key. We require a trusted authority (the key generation center) to compute the private key $sk_A$ that corresponds to the public identity string $ID_A$ and this trusted authority has to check whether $ID_A$ (e.g., the email address) indeed corresponds to $A$ and then issues the private key $sk_A$ corresponding to the identity $ID_A$. Since the private keys are generated with respect to some public parameters, every party in the system needs to be in possession of an authentic copy of the public parameters (this is similar to a root CA certificate in certificate-based crypto).

Pros and Cons

In theory, the main advantage of identity-based crypto and in particular identity-based encryption is that you do not need to obtain the public key of the recipient but simply can use the recipients identity (=public key) for encryption and the recipient actually does not even need to be in the possession of the respective private key at the point of time when the ciphertext is produced.

In practice, this, however may be not that easy to achieve as theory makes it look like.

Actually, there are various issues which are discussed in the papers I have linked in my previous comments, but I think the most relevant issues are:

  • Key generation: In traditional public key crypto users generate their keys locally and they are only known to them, while in the identity-based setting the keys are generated by the trusted authority (inherent key escrow - the party may decrypt all user's ciphertexts and or may issue signatures on behalf of users. Since the latter is also a problem in certificate-based systems, i.e., the CA can always produce valid certificates for users and thus sign on their behalf, the decryption issue seems to be far more problematic). In theory, there is the possibility of distributed key generation in context of identity-based systems, i.e., more than one key generation centres are involved in private key generation, but I doubt that they will really see wide deployment/application.

  • Revocation: Certificate-based approaches, e.g., PKIX, employs certificate revocation lists or certificate status protocols to check whether a private key has been compromised. If one wants to use the full power of identity-based systems, then ideally the identity (public key) is some information everyone knows, e.g., an e-mail address. But what happens if the corresponding private key gets compromise? Close the email address and choose a new one to get issued a new private key (that does not seem to be really possible in practice for various reasons). Thus, identities need to contain some additional information such as a key expiration date, e.g., mail@bla.com||expiry_date. Now, this forces public keys to be strings that are no longer that well known to other users and require look-ups (sounds similar as whats done in certificate-based crypto). Furthermore, what happens when the key is compromised before the expiry_date? One needs some mechanisms to signal and check that keys have been compromised (sounds similar as whats done in certificate-based crypto). So where are the theoretical advantages now?

Moreover, in what environments the identity-based systems is recommended(or needed) and why?

I would say that, since distributed key generation has not really shown to be used in practice, identity-based crypto is more for closed environments (enterprises, maybe sensor networks) and not for open environments. Essentially, in any situation where key escrow is not such an issue, key renewal can be efficiently performed and revocation checks can be made efficient, identity based crypto may be an alternative.

Anyways, it seems that a hybrid between identity-based crypto and certificate-based crypto seems more realistic.

There is also something in between:

Certificateless public key cryptography is inbetween these two approaches. It aims to get rid of the problem that the key generation center gets to know the entire private keys of all users. In this approach the key generation center only computes a partial private key of user $A$ based on the identity $ID_A$ and the user then combines this partial private key with some secret information (only known to him). Then the user needs to take the public parameters of the key generation center and combines the secret with this parameter to obtain the user's public key. The advantage here is, that this public key does no longer need to be certified, since it contains the identity $ID_A$ of user $A$ and if the key generation center is trusted (and the public parameters of the key generation center are authentic) one can assume that the user associated to $ID_A$ really corresponds to $A$ and holds the corresponding private key.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.