Patent Application
20070143608
The invention relates to computer communication network security, and more particularly to communication system preserving privacy.
At present, public key cryptosystems are widely used. Conventionally, a number of public key cryptographic encoding and decoding techniques are readily available to provide some degree of security as well as privacy. For example, U.S. Pat. No. 4,405,829, issued to Rivest, et al., and El Gamal (Tahir , A public-key cryptosystem and a signature scheme based on discrete logarithms, Advances in Cryptology Proceedings; CRYPTO 84, pages 10-18, 1985) are technologies well recognized in the field. The teachings of the Rivest patent and El Gamal are incorporated as reference.
With traditional public key cryptosystems such as RSA and El Gamal, to securely communicate with other parties, a user is required to disclose his/her public key to the outer world. In most cases, however, the user possesses only one public/private key pair, i.e. one public key and its corresponding unique private key. This typical usage of a public key cryptosystem has the unintended consequence of making the user's public key properly serve as his/her identity. It means that even if a privacy concerned user is protected by this kind of public key cryptosystem as well as other well designed privacy protection measures, an adversary is still capable of correlating the activities of the user being protected through the collection and observation of information released by the user based on the pattern of usage of the unique public key.
Within traditional public key cryptosystems, such as those disclosed by RSA and El Gamal, if a user is concerned that her/her single public key may violate her/her privacy, one possible resort is forcing the concerned individual to possess several distinct public keys and release each of the public keys to different correspondents with caution.
Besides possessing many public key pairs, Waters et al. have proposed a method making use of the El Gamal cryptosystem to realize an Incomparable Public Keys Scheme, by which a user can simultaneously possess several public keys wherein all these public keys correspond to a single private key. See B. R. Waters, E. W. Felten, A. Sahai, Receiver Anonymity via Incomparable Public keys, CCS'03, Washington, D.C., USA, pp.112˜121. (hereinafter “Waters”). The teaching of Waters is also incorporated as reference.
As discussed above, a user may possess several public keys. However, in most cases, when a person A gets a public key, the public key must be certified by someone else. For example, the public key can be certified by well known Certificate Authority (CA), or the public key can be certified by the person's friend C. If a third person B sees the pubic key and its certificate, said person may trust the public key either because B trusts in CA or alternatively, B trusts in C.
In the case where the user possesses several public keys, one possible way to certify these public keys is to ask CA to certify each of them, as shown in
Another possibility is to ask some friends to certify each of the public keys, as shown in
In addition to the certification of public keys, the above drawbacks of solutions that include a CA centric solution and friend certification solution also exist in many other situations where several pieces of user data need to be certified.
The invention provides a malleable pseudonym certificate system and the method for a communication network.
According to one aspect of the invention, a computing apparatus for a user to certify a data in a communication network is provided. The networking includes a trusted entity and at least one verifier. The computing apparatus comprises: a root proof unit, operatively coupled to the network, the root proof unit being adapted to receive a root proof from the trusted entity; a pseudonym certificate generating unit, operatively coupled to the root proof unit, the pseudonym certificate generating unit being adapted to generate at least one pseudonym certificate based on the root proof; and a transmission unit, operatively coupled to the pseudonym certification generating unit, the transmission unit being adapted to transmit said user's data, coupled with the pseudonym certificate, to the communication network.
According to another aspect of the invention, a method for a user to certify a data in a communication network is provided. The networking includes a trusted entity and at least one verifier. The method comprises: receiving a root proof from the trusted entity; generating at least one pseudonym certificate based on the root proof; and transmitting said user's data coupled with one pseudonym certificate to one verifier.
According to another aspect of the invention, an apparatus for managing certificates in a communication network is provided. The networking includes at least one user and at least one verifier. The apparatus comprises: a system parameter computing unit being adapted to compute system parameters; a parameter publishing unit, operatively coupled to the system parameter computing unit, the parameter publishing unit being adapted to publish shared system parameters which are to be shared by the user and verifier; a root proof request receiving unit, operatively coupled to the network, the root proof request receiving unit being adapted to receive a root proof request from the user; and a root proof generating unit, operatively coupled to the root proof request receiving unit and the system parameter computing unit, the root proof generating unit being adapted to generate a root proof for the user in response to the root proof request, the root proof being used for the user to generate a plurality of pseudonym certificates.
According to another aspect of the invention, a method for managing certificates in a communication network is provided. The networking includes at least one user and at least one verifier. The method comprises: computing system parameters; publishing shared system parameters which are to be shared by the user and verifier; receiving a root proof request from the user; and generating a root proof for the user in response to the root proof request, the root proof being used for the user to generate a plurality of pseudonym certificates.
According to another aspect of the invention, a malleable pseudonym certificate system for a user in a communication network is provided. The networking includes a trusted entity. The system comprises: a root proof unit, operatively coupled to the network, the root proof unit being adapted to receive a root proof from the trusted entity; a pseudonym certification generating unit, operatively coupled to the root proof unit, the pseudonym certification generating unit being adapted to generate at least one pseudonym certificate based on the root proof; a transmission unit, operatively coupled to the pseudonym certification generating unit, the transmission unit being adapted to transmit the user's data, coupled with the pseudonym certificate, to the communication network; and a verifier unit, operatively coupled to the communication network, the verifier unit being adapted to verify the user's data by the pseudonym certificate received.
According to another aspect of the invention, a method of certifying a user's data by a pseudonym certificate in a communication network is provided. The networking including a trusted entity and at least one verifier. The method comprises: issuing a root proof from the trusted entity to the user; generating at least one pseudonym certificate based on the root proof by the user; and transmitting the user's data coupled with one pseudonym certificate to one verifier, the verifier verifying the user's data by the pseudonym certificate.
According to another aspect of the invention, a manufacturing article is provided. The manufacturing article has a machine readable medium with instructions recorded thereon which, when executed by one or more processors, causes the processors to: receive a root proof from a trusted entity; generate at least one pseudonym certificates from the root proof; and transmit a data, coupled with one of the pseudonym certificates, to a verifier.
According to another aspect of the invention, a manufacturing article is provided. The manufacturing article has a machine readable medium with instructions recorded thereon which, when executed by one or more processors, causes the processors to: compute system parameters; publish shared parameters which are to be shared by all users of a network; receive a root proof request from one of the users of the network; and generate a root proof for the user, the root proof being used for the user to generate a plurality of pseudonym certificates.
The malleable pseudonym certificate system has several advantages, especially when used with anonymous public keys. The user can generate trustworthy anonymous public key where the anonymous public key is assured by pseudonym certificate as CA certified. The function of user privacy protection is totally distributed. The user generates distinct anonymous public keys by him or herself, and distinct pseudonym certificates by him or herself as well. The certificate authority's intervention is minimized, hence making lightweight implementation of CA probable. The user cannot abuse anonymity capability because the pseudonym certificate is traceable at the CA side.
The foregoing and other objects of the invention, the various features thereof, as well as the invention itself, may be more fully understood from the following description, when read together with the accompanying drawings in which:
[Anonymous Public Key]
This application is related to a novel Anonymous Public Key (APK) technique raised by Ke ZENG and Tomoyuki FUJITA. The detailed content of APK technique can be found in a co-pending Chinese patent application No. 200410090903.X, filed on Nov. 10, 2004 by NEC (China) Co., Ltd., entitled “Method, Devices and Systems for Generating Anonymous Public Keys in a Secure Communication System”.
Firstly, the technical solution of APK will be explained in the following description.
As discussed above, a user may want to possess several public keys. By employing multiple public key pairs where each distinct public key has a corresponding distinct private key, conventional public key cryptosystems can mitigate the privacy concern to some extent. However, as the number of public keys increases, the managing cost of public key pairs for individual increases. Further, as the number of private keys increases, the security risk of loss or disclosure of private keys increases.
The Incomparable Public Keys Scheme generates new public keys by utilizing different generators to construct the public key of the El Gamal cryptosystem, which makes computation optimization difficult. For example, (g, ga) and (h, ha) are different public keys generated by Waters' Incomparable Public Keys Scheme, where g and h are different generators. Conventionally, the El Gamal cryptosystem makes use of only one generator hence it can be benefited by calculating the power of generator off-line and maintaining only one table of the power of generator. Waters' scheme requires either maintaining several tables of the power of different generators, or on-line computation, neither of which is very desirable in terms of computation optimization and cost management.
We bring forward an Anonymous Public Key (APK) technique. APK is distinctive in that end user can by herself generate mass public keys while only one private key is to be maintained and preserved.
APK technique will be described with reference to
In APK technique, the term “group” refers to the mathematics concept defined as follows unless otherwise indicated:
For example, the set of integers Z with operation of addition forms a group. The identity element is 0 and the inverse of an integer a is the integer −a. For more information, please refer to Handbook of Applied Cryptography, available online at http://www.cacr.math. uwaterloo.ca/hac/.
Communication systems in accordance with the APK technique may have several terminals and several communication channels.
As can be seen in
It should be pointed out that the Sender may be designed in such a way that it always generates a different public key (Step S33), without relying on any existing keys. However, as can be appreciated by those skilled in the art, the use of an existing pool of public keys will significantly reduce the computation overhead, since manipulation of the existing keys is inherently less computation-intensive than computing from scratch.
It should also be pointed out that the Sender and Receiver in
Now reference is turned to
The Encoding Device 48 and the Decoding Device 47 in
Note that in
Next, description will be made to the process of the APK Generating Device 49 of
Among the above four exemplary kinds of groups, the first group may have the best security performance, while the latter three are more commonly used in the art. The “finite cyclic” nature of group G guarantees that the result of group exponentiation operation will eventually be mapped into group G; however the mapping methods may vary from group to group. Besides, it also guarantees the existence of a generator.
Then, the Subgroup Selector 52 selects a subgroup of G of order m, where m≦n (Step S61). If m is selected as a prime, it will have the preferred security performance. Please note that the subgroup can be selected as G itself, which also means m=n. As in an alternative complementation, on the premise that after the group G is determined or selected, the selection of the subgroup can be omitted, which also means G itself is implicitly selected as the subgroup, since G is a subgroup of itself mathematically. That is also to say, when G itself is selected as the subgroup, which causes m=n, such a selection is seemingly dismissed. Of course, if the selection of the subgroup is omitted, the Subgroup Selector 52 (as described in
Then, the Integer Selector 56 selects an integer as the private key x, such that x satisfies 1<|x|<m (Step S62). It is to be understood that one terminal may have a plurality of private keys, although the description herein is focused on how to generate a plurality of public keys from one private key, for the sake of simplicity.
Then, the Generator Selector 53 selects and fixes a generator g of group G (Step S63). If G is a finite cyclic group, it always has at least one generator. It is to be noted that the selections of g and x is independent from each other. That is to say, although Step S62 is described prior to Step S63 here, the order of their performance can be reversed or they can be performed in parallel.
After the selection of G, m, x and g, an integer r is selected as the indicator that satisfies 0<|r|<m to generate a new public key under the control of the Control Unit 55 (Step S64).
With the selection of G, m, x, g and r, a new public key is generated with the computation of y1=gr and then y2=y1x (Step S65). Then the public key (y1,y2) can be released (Step S66) to the Receiver for encryption. Of course, there may be other information that is also released together with the public key.
It is to be noted that the selection of g, x, and r has no sequential and dependency requirement between their selections, such that Steps S62, S63, S64 can be performed in any order, sequentially or concurrently. In addition, the selection of g, x and r may be at random or in accordance with some criteria as desired.
Alternately, some of the aforementioned procedures may be omitted by the Control Unit 55, but performed elsewhere. For example, the group G and the subgroup can be assigned by a third party such as an entrust organization. Hence the Control Unit 55 skips steps of selecting the group and subgroup, since they are now determined externally. Further, if one anonymous public key has been previously generated, it is for certain that the group, subgroup, generator and private key all have been selected and fixed. Therefore when a new public key is to be generated, the Control Unit 55 skips these four steps and goes directly to the following steps.
If y1 or y2 is originally outside the range of group G, they must be mapped into group G. The mapping methods may vary for different groups. However, the cyclic group G guarantees the existence of such mapping method.
It is to be noted that the foregoing steps may be performed either in one single device/module (with integrated or discrete components) of a system, or in a distributed manner with respective devices of the system performing some of the steps, respectively.
An example of the group, subgroup and generator selection is described below. Suppose group Zp* is selected where p=11, hence Z11*={1, 2, 3, 4, 5, 6, 7, 8, 9, 10}. Since 11 is a prime, mathematically the order of Z11 * is 11−1=10. The element 2 is a generator of Z11* as can be easily verified that Z11*={2i mod 11/i=0,1, . . . ,9}. Since a group is also a subgroup of itself, the subgroup may be chosen as Z11*. Another choice of subgroup for example is {1, 3, 4, 5, 9} which has the generator 3 of order 5. Again it's easy to verify that 35=1 mod 11.
Furthermore, as can be appreciated by those skilled in the art all of the devices and components can be implemented in hardware, software, firmware or the combination thereof depending upon various considerations.
The exemplary method primarily described in
To encrypt a plain text M, M is first represented as an element of G (for example, M is represented as its ASCII code) (Step S70), then an integer k is selected as the designator satisfying 1<|k|<m (Step S71) and a pair of values are computed as follows (Step S72)
C1=y1k, and
C2=M⊚y2k,
where C1 and C2 are group G members. All of these operations can be done by the Encoding Device 48 in
At this time, the cipher text of the message M is obtained as C=(C1, C2) (Step S73) and it can be sent out over a communication channel by the Sending Unit 44.
For a message M that is outside the range of group G to be encoded, it must be transformed into several group members before encoding. Following subsequent decoding, the recovered group members may be transformed back to the original message. The transformation methods may vary for different groups. One example is breaking the message into several blocks, each of which is a member of group G, and concatenating all the blocks to reconstruct M.
At the other side of the communication channel, the cipher-text message C is received (Step S74). To retrieve the plain text M from the cipher text C, first it has to be decided between two ways, direct exponentiation or not (Step S75). If yes, rb=C1x is first computed (Step S76) and then M is obtained by computing M=C2Ørb (Step S77); otherwise, ra=C1−x is first computed (Step S78) and then M is obtained by computing M=C2⊚ra (Step S79).
After successful decryption of a cipher text (C1, C2), depending on the implementation of decryption, the APK Generating Device 49, in accordance with the APK technique, may make use of the received cipher text as well as the intermediate decryption output ra to generate a new anonymous public key in the form of (y1=C1−1, y2=ra). Similarly, the APK Generating Device 49 may make use of the received cipher text as well as the intermediate decryption output rb to generate a new anonymous public key in the form of (y1=C1, y2=rb). In either way of generating a new anonymous public key, the exponentiation operation is avoided and computation efficiency is enhanced.
Furthermore, when a single anonymous public key (y1, y2) is provided, the APK Generating Device 49 may generate a new anonymous public key in the form of (y2, y2x). This method can be utilized multiple times to generate a chain of public keys. This way, storage consumption of the public keys generated are heavily reduced since the second portion of the public key, y2, is identical to the first portion of its following. For a chain of w public keys, up to (w−1)/2w percentage of storage are saved which implies approximate 50% saving for w large enough.
In APK technique, since the public keys are generated with the same generator based on the form of powers of the generator, the powers of the generator g can be reused to generate a series of public keys, which involves multiplication, instead of exponentiation, thus saving the memory storage and accelerating the computation. Meanwhile, since only one table of the powers of the generator needs to be maintained in the decoding device, the computation of new public keys can be performed off-line.
For example, in an complementation, when a cipher text message C=(C1, C2) is received in the decoding device, C1 can be retrieved and utilized to generate new public keys. As described, C1=y1k=grk, and grk can be saved to generate new public keys because the product “rk” is only another integer. It is to be noted that although grk can be saved to generate new public keys, the value of rk may still be unknown to the decoding device, unless the encoding device revealed k when sending the encrypted message.
When a single anonymous public key (y1, y2) is provided, the APK Generating Device 49 may generate a new anonymous public key in the form of (y1×y1, y2×y2), where × is group multiplication. In general, if there are provided several anonymous public keys (y11, y21), (y12, y22), . . . , (y1j, y2j), j≧2, based on the plurality of stored powers of g, y11=gr1, y12=gr2, . . . , y1j=grj, and y21=y11x, y22=y12x, . . . , y2j=y1jx, a new public key can be computed as (y1(j+1)=y11y12 . . . y1j, y2(j+1)=y21y22 . . . y2j), where y11y12, . . . , y1j, is the product of y11, y12, . . . , y1j, y21y22 . . . y2j is the product of y21, y22, . . . , y2j. Clearly, to generate a new anonymous public key, the exponentiation operation is replaced by multiplication and computation efficiency is enhanced. Since multiplication can be carried out online, new public keys generated in this way may not need to be pre-computed, which directly implies saving of storage space.
The above optimization techniques may be jointly used to generate new anonymous public keys. For instance, upon receiving and after successful decryption of a series of cipher texts (C11, C21), (C12, C22) . . . (C1j, C2j), j≧2, the APK Generating Device 49 can make use of the received cipher texts as well as the intermediate decryption outputs rb1, rb2, . . . , rbj to generate a new anonymous public key in the form of (y1=(C11C12 . . . C1j), y2=(rb1rb2 . . . rbj)), where C11C12 . . . C1j is the product of C11, C12, . . . , C1j, rb1rb2 . . . rb j is the product of rb1, rb2, . . . , rbj.
Furthermore, with the computation of y2, a series of public keys can be computed as (y2w1, y2w2), where w1=xw, w2=x(w+1), w≧0. Furthermore, all of the results, specifically the powers of g, obtained in this computation can be utilized to generate further public keys.
Furthermore, based on C1 retrieved from the cipher-text message C, the decoding device can generate more new public keys. For this purpose, C1x and C1−x can be computed and saved, and then two series of public keys can be generated. In general, when a plurality of encrypted messages CC1=(C11,C12), CC2=(C21,C22), . . . , CCj=(Cj1,Cj2 ) are received, for the case of C1x, a series of new public keys can be generated as ((C11C21 . . . Cj1)u1, (C11C21 . . . Cj1)u2), where C11C21 . . . Cj1 is the product of C11, C21, . . . , Cj1, j≧1, u1=xu, u2=x(u+1) and u≧0, and for the case of C1−x, another series of new public keys can be generated as ((C11C21 . . . Cj1)v1, (C11C21 . . . Cj1)v2), where C11C21 . . . Cj1 is the product of C11, C21, . . . , Cj1, j≧1, v1=−xv, v2=−x(v+1) and v≧0. Furthermore, all of the results, specifically the powers of g, obtained in this computation can be utilized to generate further public keys.
[Malleable Pseudonym Certificate]
In the flowing description, the general conception of the invention will be explained.
The APK technique, as described in the aforementioned co-pending application, poses the question on how to certify mass anonymous public keys. For a solution that can certify mass anonymous public keys, we hope it to be:
1. Secure. Nobody can forge the certificate and no one can hide as the holder of a certificate.
2. Reliable. The user privacy will not be disclosed through any certificate.
3. Revocable. In the event that a user abuses anonymity, the real identity of the user can be exposed.
4. Trustworthy. The certificate has business significance.
5. Decentralized. As with the distribution method in APK, the certificate solution should be decentralized.
6. Efficient. The less involvement of third party authorities, the better.
As described above, traditional certification methods have many drawbacks. Further, since APK is a distributed privacy protection solution, a centralized certification solution is not suitable for the APK solution.
Therefore, a distributed solution for certifying user's data is brought forward, i.e., Malleable Pseudonym Certificate (MPC) solution.
The Malleable Pseudonym Certificate (MPC) solution of the invention is a novel solution to certify mass anonymous public keys. Unlike the traditional solution where all the certificates are generated and issued by a trusted entity, MPC solution is a distributed solution in which a user whose data needs to be verified by others generates by him or herself pseudonym certificates from a root proof acquired from a trusted entity.
The root proof may be a certificate issued by the trusted entity for the user to generate pseudonym certificates. Hereinafter, such a certificate is called as a root certificate. The root proof also may be a group private key, by which the user can generate pseudonym certificates in the name of a group member. However, the root proof is not so limited. The root proof may be any data by which the user's credence can be proved and pseudonym certificates can be generated by certain algorithm.
User U is a user in a network who communicates with other users via the network. During the communication sessions, some of U's data may be required to be verified by another user or peer. For example, user U's data DATA1 is to be verified by user V1, U's data DATA2 is to be verified by user V2, U's data DATA3 is to be verified by user V3, and so on. Hereinafter, the user or peer who wants to verify user U's data to gain confidence is called as a verifier.
DATA1, DATA2 and DATA3 may be different public keys of the user for different communication sessions. In one implementation, these data are incomparable public keys or APKs. However, the data are not limited to public keys. Data to be certified can be any data for various purposes.
In order to authenticate the data, user U sends the data to the verifier (V1, V2, V3, etc), wherein the data is equipped with a certificate, such as PC1, PC2, PC3, etc. In the MPC solution, these certificates are all generated from a root proof issued from a trusted entity to user U. It's notable that these certificates (PC1, PC2, PC3, etc) are computed by user U himself or herself without any intervention of the trusted entity. The verifier verifies user U's data by such an attached certificate, and the data can be assured by the certificate as certified by the trusted entity. If the verifier trusts said trusted entity, he can believe in the authenticity of the data of user U.
The trusted entity may be a CA, a trusted group, a friend of U or other party by whom U's credence can be proven.
In the MPC solution in accordance with the present invention, while the verifier can verify and gain confidence by such certificate that U's data is certified by the trusted entity, the certificates can be generated by the user such that the verifier can by no means figure out the real identity of user U, i.e., the holder of the user's data. Therefore, the certificates generated by the user hereinafter are called as pseudonym certificates.
In the event that the user's data is APK, each pair of APK and pseudonym certificates can be shown to a verifier, e.g., V1. While V1 verifies and gains confidence that the APK is certified by the trusted entity, V1 can by no means figure out the holder of the APK and pseudonym certificate pair. Even if the user communicates with V1 many times, each time he or she shows a distinct pair of anonymous public key and pseudonym certificate, so V1 is unable to tell whether he or she is talking with the user or not.
At step 81, the user gets root proof from a trusted entity. For example, the user gives his/her basic data (hereinafter called root data) and the user's proof thereof to CA. CA performs an identification examination of the user's root data and the user's proof of root data. After the user passes CA's identification examination, CA issues a certificate to the user.
At step 82, the user generates pseudonym certificates from the root proof. From the same roof proof, the user can generate a plurality of distinct pseudonym certificates.
At step 83, the user sends a user's data, equipped with one pseudonym certificate, to a verifier.
At step 84, the verifier verifies said user's data by the pseudonym certificate. Since the data is proved by the pseudonym certificate as certified by the trusted entity, the verifier can have confidence that the user's data is believable if the verifier trusts in the trusted entity. Then, the verifier can communicate securely with the user based on said data. For instance, in the case that the user's data is an anonymous public key, the user may digitally sign his/her message or the verifier may encrypt message for him or her, all based on his/her anonymous public key. However, the user's data is not limited to an anonymous public key of the user. For example, it may be an incomparable public key of the user.
As can be seen from
Further, with the MPC solution in accordance with the present invention, the user's root proof can be stored by the trusted entity such that the pseudonym certificate is traceable at the trusted entity.
In the event that the user U behaves inappropriately, e.g. he/she digitally signs a message but later disavows it, the victim can send the user U's pseudonym certificate back to the trusted entity. It would be the trusted entity and only the trusted entity that has the ability to figure out the real holder of a pseudonym certificate.
Consider a concrete example, U generates a paired anonymous public key and pseudonym certificate. Then he/she communicates with V1, demonstrating the key and certificate. Based on the pseudonym certificate, V1 verifies that the anonymous public key is truly certified by the trusted entity. Therefore, when he/she signs that he/she will pay V1 50$, V1 sends an e-book he/she authored to U. Because V1 only sees the anonymous public key and pseudonym certificate, he/she does not know the real identity of the buyer. Nevertheless, if U bilks, V1 can send the pseudonym certificate to the trusted entity by which the trusted entity can expose the real holder of the pseudonym certificate. In this case, the holder is U who will consequently receive a penalty. In this way, the user cannot abuse the anonymity capability of the system.
In the following description, the first embodiment in accordance with the invention will be described with reference to
According to the first embodiment, the trusted entity is a Certificate Authority CA. The user U's data to be verified by verifiers are anonymous public keys of the user U.
CA issues a root certificate (RC) to U provided that U passes the personal identification examination. U generates pseudonym certificates from the root certificate for his/her anonymous public keys. Then, U sends an anonymous public key (APK1, APK2, APK3, . . . ) equipped with a pseudonym certificate (PC1, PC2, PC3, . . . ) to a verifier V (V1, V2, V3, . . . ). V verifies pseudonym certificate received from U and accepts the certificate if predetermined conditions are met.
In the first embodiment, U can derive a pseudonym certificate for certain anonymous public keys from RC without intervention of CA, while V can judge the authenticity of U on the basis of the pseudonym certificate with no need to involve CA as well.
In addition, V will store data collected from U and under certain circumstances, e.g. U behaves illegally, V can hand in data collected from U to CA and CA is capable of disclosing the real identity of U.
In the following description, it is supposed that the cryptography is based on the Strong RSA (SRSA) Assumption. For the details of SRSA, please see N. Baric, B. Pfitzmann, Collision-free Accumulators and Fail-stop Signature Schemes without Trees, Advances in Cryptology—EUROCRYPT'97, pp. 480˜494, 1997; and R. Cramer, V. Shoup, Signature Schemes Based on The Strong RSA Assumption, ACM Transactions on Information and System Security, vol. 3(3): 161˜185, 2000, which are incorporated as reference.
Further, some proof techniques may be used in the embodiments of the invention, which allow one prover to convince the verifier with respect to knowledge of a certain value, while no useful information regarding the value itself is leaked.
In the first embodiment in accordance with the invention, so-called knowledge proof technique is used (see S. Goldwasser, S. Micali, C. Rackoff, The Knowledge Complexity of Interactive Proof Systems, 17th ACM Symposium on Theory of Computation, pp. 291˜304, 1985, which is incorporated as reference). Many methods have been proposed to prove the knowledge of discrete logarithm in zero-knowledge (see A. Fiat, A. Shamir, How To Prove Yourself: Practical Solutions to Identification and Signature Problems, Advances in Cryptology—CRYPTO'86, pp. 186˜194, 1986; D. Chaum, Demonstrating Possession of a Discrete Logarithm without Revealing It, Advances in Cryptology—CRYPTO'86, pp. 200˜212, 1987; D. Chaurr., J. H. Evertse, J. van de Graaf, An Improved Protocol for Demonstrating Possession of Discrete Logarithms and Some Generalizations, Advances in Cryptology—EUROCRYPTO'87, pp. 127˜141, 1987; D. Chaum, T. P. Pedersen, Wallet Databases with Observers, Advances in Cryptology—CRYPTO'92, pp. 89˜105, 1993; and K. Sako, J. Kilian, Receipt-Free Mix-Type Voting Scheme-A Practical Solution to the Implementation of a Voting Booth, Advances in Cryptology—CRYPTO'98, pp. 393˜403, 1998, which are incorporated as references).
In the first embodiment of the invention, the notation (1)
KP{(x1, . . . , xi)/(g1, y1), . . . , (gi, yi):y1=g1x
will be used to denote knowledge proof between the prover and verifier, on common input (gj,yj), where gj generates (gj), j=1, . . . , i, that proves the knowledge of xj such that yj=gjx
The above notation (1) could be conceivably generalized to the case of proof for multiplication representation. For instance,
KP{(x1, x2)/(g1, h1, y1), (g2, y2):y1=g1x
denotes zero-knowledge proof of x1 and x2 such that y1=g1x
Next, The details of the method according to the first embodiment of the invention will be described with reference to
The method according to the first embodiment mainly consists of five phases: system startup, RC request, MPC deriving, anonymous authentication, and tracing (if necessary).
At step 101, CA generates SRSA modulus nc. The factorization of nc is kept secret.
At step 102, CA generates primes p and q such that p−1 is divided exactly by q.
At step 103, CA computes integers lq=|q|, i.e., the length of q.
At step 104, CA selects one generator g of GF(q) (a finite field of order q) from Z*p.
At step 105, CA selects integers ca, cb and cc from QR(nc).
At step 106, CA selects an integer lc<lq.
The above mathematical notions can be found in A. Menezes, P. van Oorschot, S. Vanstone, Handbook of Applied Cryptography, CRC Press, 1996, which is incorporated as reference. Finally, at step 107, CA publishes nc, p, q, g, lq, ca, cb, cc and lc to the network, e.g., the Internet.
According to system parameters published by CA, user U selects randomly its own private key xu ∈(0,2l
At step 112, the user U computes his/her root public key(g, yu=gx
To acquire RC, U needs to authenticate his/her identity to CA while CA must make sure that yu has not been used by some other user as public key.
At step 121, the user U computesau=cax
At step 122, the user U submits his/her root public key(g, yu) and au to CA.
At step 123, the user U and CA perform knowledge proof:
KP{xu)/(g, yu), (ca, au):yu=gx
If the knowledge proof is successful, at step 124, CA selects a sufficiently large random prime e
At step 125, CA issues (eu,su) to (g, yu) as RC to the user U.
At step 126, CA stores demasking e
At step 127, the user U verifies that congruence cb=sue
Said RC is the two tuple (eu,su), where eu is indeed a RSA public key and su is the digital signature of cb/au. However, as will be demonstrated in the next phase, upon the provision of this single signature, U can effectively derive certificates for all his/her anonymous public keys. RC is a digital signature that signs all anonymous public keys in compliance with the form (gr,yur).
As shown in
As shown in
The pseudonym certificate is actually the two tuple ({tilde over (s)}u, {tilde over (y)}u).
Now, U has cb={tilde over (s)}ue
After preparation of an anonymous public key and pseudonym certificate, U can present them to the verifier.
At step 151, the user U submits an anonymous public key (y1r=gr,y2r=yur) and pseudonym certificate ({tilde over (s)}u, {tilde over (y)}u) to the verifier V.
At step 152, V computes yb=cb/{tilde over (y)}u (mod nc).
At step 153, the user U and the verifier V performs the knowledge proof:
KP{x1, x, x3)/({tilde over (s)}u, {tilde over (y)}u), (ca, cc, yb), (y1r, y2r):{tilde over (y)}u={tilde over (s)}ux
At step 154, V stores a transcript of the above knowledge proof for possible tracing.
Since CA has stored demasking eu in its database under the name of the user U at step 126 in
After V accepts the anonymous public key of U as CA CMS certified and carries out a transaction with U, if U behaves inappropriately, V can provide evidence of U's inappropriate behavior to CA and ask CA for help. CA will definitely inspect the evidence received from V. If, from the view point of CA, there is a sound reason for V to know the real identity of U, CA can cooperate with V to ascertain the real identity of U.
At step 161, V submits the pseudonym certificate ({tilde over (s)}u, {tilde over (y)}u) to CA.
At step 162, for all demasking eu stored in its database, CA computes {tilde over (s)}ue
A matching {tilde over (s)}ue
Next, the exemplary apparatus at the user side and CA side will be described with reference to
As shown in
In the case that the root certificate is requested by a digital request via the network, the user apparatus 170 may further comprise a root proof requesting unit 174 for generating a request for RC and transmitting the request to CA.
The user's data to be verified by a verifier may be a public key, an incomparable public key, an anonymous public key, etc. In the case of anonymous public key, the user apparatus 170 may further comprise an anonymous public key generating unit 175 for generating anonymous public keys. The detailed structure of the anonymous public key generating unit 175 can be found in the above description of the APK technique. When the user's data to be certified by the pseudonym certificate are not anonymous public keys, the anonymous public key generating unit 175 can be replaced by a corresponding data generating unit.
If the issuance of RC requires the proving process between the user and CA or the verifier requires a knowledge proof during the authentication process, the user apparatus 170 may further comprise a proving unit 176 for performing the proving operation with the verifier or CA.
The above mentioned units may each comprise a memory for storing data used by the respective unit. In another implementation, the user apparatus 170 may comprise a storage unit 177 for storing data used by all the units during the operation of the apparatus.
In most cases, the user will also need to verify another user's received data. Therefore, user apparatus 170 may comprise a verifying unit 178 for verifying the data received from another user by the pseudonym certificate attached thereto.
The root proof unit 171, the transmission unit 173, the root proof requesting unit 174, the proving unit 176 and the verifying unit 178 may transmit/receive data to/from the network through respective communication ports or a communication unit in the user apparatus 170 coupled to the above units for communicating with other apparatus via the network.
The above units are coupled to each other to perform the processes according to the first embodiment of the invention. When the units are implemented as hardware modules, they could be coupled with each other by a data bus.
As shown in
In the case that the user's RC request should be examined before a root certificate is issued, the CA apparatus 180 further comprises an examining unit 185 coupled to the root proof request receiving unit 183 for performing identification examination in response to a user's RC request. The identification examination may include the above mentioned knowledge proving process.
In the case that a tracing ability is desired, the CA apparatus may further comprise a tracing unit 186 coupled to the network for tracing the identity of the owner of a pseudonym certificate received from a verifier using stored demasking values of the root certificates generated by the root proof generating unit 184.
The above mentioned units may each comprise a memory for storing data used by the respective unit. In another implementation, the CA apparatus 180 may comprise a storage unit 187 for storing data used by all the units during the operation of the apparatus. For example, the RCs generated by root proof generating unit 184 can be stored in the memory inside the root proof generating unit 184 or be stored in the storage unit 187.
The above units are coupled to each other to perform the processes according to the first embodiment of the invention. When the units are implemented as hardware modules, they could be coupled with each other by a data bus.
The parameter publishing unit 182 and the root proof request receiving unit 183 may transmit/receive data to/from the network through respective communication ports or a communication unit in the CA apparatus 180 coupled to the above units for communicating with other apparatus via the network.
The above described user apparatus and CA apparatus are merely examples. However, the components included in the apparatus are not limited to those units described, and the particular structure may be modified or changed. For example, the apparatus may comprise other units that are typically installed in a computing apparatus in the network, such as an I/O interface for inputting and outputting the data, various communicating interfaces for connecting to other apparatus via the network, a controller for controlling the operation of each unit, etc. They are omitted from the figures since such units are common sense in the art, and a person skilled in the art would easily consider adding them to the apparatus described above.
The first embodiment of the invention has been described as an example. However, the invention is not limited to the particular details described in the first embodiment. For example, the user's public key can be generated by other methods. The Incomparable Public Keys (see B. R. Waters, E. W. Felten, A. Sahai, Receiver Anonymity via Incomparable Public Keys, CCS'03, Washington, D.C., USA, pp.112˜121, 2003) can be used as the user' data which is to be certified by the pseudonym certificate. Also, the user's data certified by a pseudonym certificate is not limited to a public key, but may be any data or message sent by the user. In addition, the embodiment can be modified to adapt to other proof techniques and methods of CA. Besides the algorithm described in
In the following description, the first embodiment in accordance with the invention will be described with reference to
The second embodiment of the invention takes use of a group signature scheme to produce pseudonym certificates for public keys. Here, the public keys may be incomparable public keys, anonymous public keys or any other public keys of the user.
Group signature schemes have been well studied in the past 15 years (see D. Chaum, E. van Heyst, Group Signatures, Advances in Cryptology—EUROCRYPTO'91, pp. 257˜265, 1991; J. Camenisch, M. Michels, A Group Signature Scheme Based on an RSA-Variant, Advances in Cryptology—ASIACRYPT'98, pp. 160˜174, 1998; and G. Ateniese, J. Camenisch, M. Joye, G. Tsudik, A Practical and Provably Secure Coalition-Resistant Group Signature Scheme, Advances in Cryptology—CRYPTO'2000, pp. 255˜270, 2000, which are incorporated as references). Roughly speaking, there is a group manager who sets up a group and handles admission and revocation of group members. All group members share the same group public key PKg but each member Ui has a different private key SKi. Given message m, group member Ui can sign the message on behalf of the group as s=SIG(m,PKg,SKi) where SIG(x) is a special group signature algorithm. The signatures on message m can be verified by the group public key PKg, i.e. there is a signature verification algorithm VERIF(x) that, on given PKg, s and m , VERIF(s,m,PKg) outputs valid if and only if s=SIG(m,PKg,SKi). However, it would be very difficult for the verifier to determine the signer Ui, of s. From the viewpoint of the verifier, any group member has an equal probability of being the signer of s. This interesting feature is where the name “group signature” originates.
Some group signature schemes provide a capability wherein the group manager can determine the signer Ui of s, i.e. there is a tracing algorithm TRACE (x) that, on given PKg,s and SKm, TRACE (s,PKg,SKm) outputs Ui if and only if s=SIG(m,PKg,SKi), where SKm is the private key of the group manager.
According to the second embodiment, the trusted entity is a group 190 setup by a group manager M. The user U is a member of the group, and possesses a group private key assigned to him/her. In the traditional group signature schemes, a message is signed on behalf of the group. However, in the second embodiment of the invention, the group signature is used to generate the pseudonym certificates of the public keys.
At initialization stage 201, the group manager sets up a group and publishes a group public key PKg. In addition, the group manager keeps private key SKm secret which will be utilized in tracing mal-behaving users.
At step 202, a group member U joins the group and gets his/her group private key SKu for this group.
At step 203, U computes anonymous public key apk=(gr, yur) (mod p).
At step 204, U takes apk as a piece of a message, and digitally signs the anonymous public key apk as s=SIG(apk,PKg,SKu). In this way it is obvious that, s is a group signature on apk.
At step 205, U submits s and apk to a verifier for validation, and the verifier verifies the user's anonymous public key at step 206. Since VERIF(s,apk,PKg) will output a valid response, the apk will be accepted by verifier as digitally signed by an anonymous group member. Therefore s guarantees that an anonymous group member owns the anonymous public key apk. That is to say, s is an pseudonym certificate on the anonymous public key apk.
It is obvious that the root proof in the second embodiment in accordance with the invention is a group private key of the user.
In the event that tracing is necessary, s will be presented to the group manager M, whereupon the group manager can determine and disclose the identity of U, since the tracing algorithm TRACE(s,PKg,SKm) will output U.
In the above example, the user's data is an anonymous public key. However, the user's data can be other data of the user, such as an incomparable public key, or any other public key of the user.
The user apparatus of the second embodiment in accordance with the invention is similar to the apparatus 170 shown in
As discussed above, through a group signature verification algorithm, the verifier could be convinced that the user's data is certified by a group member. However, in many cases, the verifier needs to know whether the user who sends the data signed in the name of a group member is the true owner of the data or is the true member who signs that data.
As shown in
Note that, with the traditional group signature scheme, the prover responses to the challenge message generated by the verifier and computes the group signature for the challenge message in an online fashion. Such online computation of the group signature is time-consuming and costly. Moreover, if the prover contacts the verifier several times, the verifier generates a new challenge message each time and the prover has to compute several group signatures.
With the solution of the second embodiment in accordance with the invention, it is more convenient and efficient to verify the validations of the pseudonym certificate and the user's data (i.e., his/her public key).
As shown in
It is obvious that with the above described method in accordance with the invention, the pseudonym certificate could be pre-computed, rather than computed in an online fashion in response to the verifier's challenge. That's to say, the prover could compute group signatures at spare time of the computing device at the prover side. Before contacting the verifier, the multiple pseudonym certificates as well as public keys could be already available. When contacting the verifier, the prover needs only to send the public key with the pseudonym certificate to the verifier. The verifier checks the validity of the pseudonym certificate. Then the prover proves to the verifier only the knowledge of private-key that corresponds to the public key. This proof is much efficient than group signature signing.
Assuming that the verifier has stored the public keys, which are ever verified correctly. When the verifier receives a public key with a pseudonym certificate from a prover (step 231), the verifier compares the received public key with the public keys that have been verified correctly and stored (step 232). If the received public key matches one of the stored public keys, the verifier can go directly to the knowledge proof concerning the public key (step 235). If there is no matched public key, the verifier performs group signature verification on received public key by the pseudonym certificate of the public key and a group public key (step 233). If the received pseudonym certificate passes through the group signature verification, the verifier stores the received public key as a public key that has been verified correctly (step 234), and then the process goes to step 235. Otherwise, the process ends.
If the prover decides to contact the verifier multiple times with the same pseudonym certificate, the verifier needs only to check the validity of the pseudonym certificate at the first time. In the following sessions, the verifier simply matches the public key received from the prover with its local cached public keys. If there is one matching, the verifier and prover can go directly to knowledge proof concerning the public key. This kind of usage is most efficient while anonymity and trust are all maintained.
The verifying unit 240 comprises a verification module 245 for performing verification on the group signature and the public key. The verification module 245 may be divided into group signature verification part 241 and a public key knowledge verification part 242. When receiving a public key coupled with a group signature from a prover, the verification module 245 verifies the group signature by the group signature verification part 241 using the public key received and a group public key. After the public key received from the prover is verified correctly by the group signature verification part 241, the public key knowledge verification part 242 performs knowledge proof with the prover concerning the public key received along with the group signature.
The verifying unit 240 may further comprise a memory 243 coupled to the verification module 245 and a comparison module 244 coupled to the verification module 245 and the memory 243. The memory 243 stores the public keys that have ever been verified correctly. When receiving a public key and a group signature from a prover, the comparison module 244 compares the received public key with the public keys stored in the memory 243, and notifies the verification module 245 of the result of the comparison. If the received public key is the same as one of the public keys that have ever been verified correctly, the verification module 245 skips the computation of the group signature verification algorithm, and directly performs the knowledge prove concerning the public key received along with the group signature with the prover by the public key knowledge verification part 242. If the received public key does not match any one of the stored public keys, the verification module 245 carries out the computation of the group signature verification algorithm as described above by the group signature verification part 241.
According to the invention, in the case that the trusted entity is CA, the verification on the certificate and the public key can be carried out in a similar manner. With reference to
In the case that the trusted entity is CA, the verifying unit in the verifier's apparatus also comprises a verification module. In one implementation, the verifying unit performs the knowledge prove as shown, for example, in the step 153 of
The process and apparatus for the verification of the certificate and the user's data in the two cases according to the invention have been descried above. However, the invention is not limited to the particular details described above. Modifications and changes to the process and apparatus for the verification may be made by one skilled in the art according to the particular application and algorithms.
As can be seen from the above description, according to the invention, the user can generate a trustworthy anonymous public key where the anonymous public key is assured by an pseudonym certificate as certified by a trusted entity. The function of user privacy protection is totally distributed. The user generates a distinct anonymous public key by him or herself, and distinct pseudonym certificate by him or herself as well. In one embodiment in accordance with the invention, the intervention of CA, is minimized, hence a lightweight implementation of the trusted entity is probable. Moreover, the user cannot abuse the anonymity capability because the pseudonym certificate is traceable at the CA or the group manager level.
The present invention may be implemented in hardware, software, firmware or a combination thereof and utilized in systems, subsystems, components or sub-components thereof. When implemented in software, the elements of the present invention are essentially programs or the code segments used to perform the necessary tasks. The program or code segments can be stored in a machine readable medium or transmitted by a data signal embodied in a carrier wave over a transmission medium or communication link. The “machine readable medium” may include any medium that can store or transfer information. Examples of the machine readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, an erasable ROM (EROM), a floppy diskette, a CD-ROM, an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc. The data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, etc. The code segments may be downloaded via computer networks such as the Internet, Intranet, etc.
The invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. For example, the algorithms described in the specific embodiment can be modified while the system architecture does not depart from the basic spirit of the invention. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.
| Number | Date | Country | Kind |
|---|---|---|---|
| 200510103562.X | Sep 2005 | CN | national |
