Method and device for authentication

[0002] 1. Field of the Invention

[0003] The present invention relates to information security techniques, and more particularly, to a method and a device that make it possible to hide private information itself while providing system users with prover functions based on the private information in an authentication code system that founds safety on the difficulty of an annihilator determination problem.

[0004] 2. Prior Art

[0005] Decryption keys in the prior art public key cryptography, signature keys in signature, authentication keys in authentication are characteristic information for authenticating the holding of these pieces of private information. As an example, a description will be made of an authentication code system based on an authentication system proposed in “A practical zero-knowledge protocol fitted to security Microprocessor minimizing both transmission and Memory”, Advances in Cryptology EUROCRYPT '88 (Lecture Notes in Computer Science v.330), C. G. Guenther (ed.), Springer-Verlag pp. 123-128 by Guillou and Quisquater.

[0006] FIG. 1 explains the flow of thee authentication code system.

[0007] Let n be a composite number that is difficult to factor into prime factors, G be a multiplicative group (Z/nZ)* of a residue class ring of rational integers modulo n, p be a prime number that does not divide Carmichael function λ(n) of n, R be a space of commitments, π be a function from G to R, C be a space of challenge, S be a space of message, φ be a mapping from a set-theoretic product C×S of C and S into F_p(F_pdenotes the finite field of p-elements), IεG be a public verification information, and xεG satisfying Ix^p=1 be an authentication characteristic information.

[0008] A holder of characteristic information x can send any message MεS safely because pretending and tampering are prevented by performing the operation of a prover 200 as described below.

[0009] (1) Generate a random number kεG and send a commitment r=π(k^p).

[0010] (2) Compute an exponent C=φ(χ,M) by a given challenge χ and a message M to be sent and send the message M and a response s=kx^C.

[0011] Anyone who can know verification information I can verify the operation of the prover 200 by performing the operation of a verifier 100 as described below, and can assure himself that the prover 200 holds authentication characteristic information and a sent message is not tampered.

[0012] (1) After the commitment r is given, send the challenge χ generated at random to the prover 200.

[0013] (2) Make sure that the given message M and response s satisfy the following relation.

[0014] r=π(s^pI^φ(χ,M)  [Expression 2]

[0015] These techniques are developed on the assumption that holders of the above-mentioned private information do not publicize it. Therefore, this allows ciphertext that can be decrypted by only persons holding these pieces of private information, signature that can be generated by only persons holding these pieces of private information, and authentication that makes it impossible for others to impersonate the holders of these pieces of private information.

[0016] Accordingly, the above-mentioned techniques can be used in only situations in which exposure of these pieces of private information is disadvantageous to the holders of them. A typical example of such situations is found in a case where the above-mentioned private information is held by only specific individuals and is characteristic information for authenticating the individuals.

[0017] In this case, the above-mentioned characteristic information plays a role similar just, to a home lock and an individual's seal. Practically, the construction of a lock and seal in the actual life as digital information can be easily implemented as a direct application of these cryptographic methods. For example, if a home lock is configured so that it is used as a verifier in the above-mentioned Guillou-Quisquater system and is unlocked only when the verification succeeds, the holding of authentication characteristic information x will be equivalent to the holding of a home lock.

[0018] 3. Problems of the Prior Art

[0019] In contrast to the above-mentioned individual's home lock case where the exposure of authentication characteristic information is disadvantageous to the individual, there exist cases where the exposure is advantageous to the exposer. These are cases where an holder of characteristic information has the right and qualification to receive specific services. In these cases, an approach cannot be taken which distributes characteristic information representing rights and qualifications to persons having the rights and qualifications and verifies that they hold the characteristic information, as is the above-mentioned case of authenticating individuals. This is because the characteristic information is passed to a third party not having the rights and qualifications since the exposure of the characteristic information is not disadvantageous to the holder of them, so that an advantage can be illegally obtained from the third person.

[0020] Hence, heretofore, three types of methods described below have been employed in place of authentication methods employing the above-mentioned public key cryptgraphic techniques without modifications.

[0021] (1) A first method is that individuals hold private characteristic information belonging to the individuals and a party to verify the holding of rights and qualifications holds individuals having the rights and qualifications and private characteristic information of the individuals. This method can be used for authentication of rights and qualifications since the leak of characteristic information would be disadvantageous to individuals.

[0022] (2) A second method is that individuals hold private characteristic information belonging to the individuals and a party to verify the holding of rights and qualifications holds individuals having the rights and qualifications and public information corresponding to private characteristic information of the individuals. This method can be used for authentication of rights and qualifications since the leak of characteristic information would be disadvantageous to individuals.

[0023] (3) A third method is that a grantor of rights and qualifications passes a signature created from characteristic information held by the grantor to a grantee of a right and qualification and a verifier authenticates the right and qualification by verifying the signature. An example of this method is found in “Online Cash Checks”, Advances in Cryptology EUROCRYPT '89 (Lecture Notes in Computer Science v. 434), J.-J. Quisquater, J. Vandewalle (ed.), Springer-Verlag, pp. 288-293 by D. Chaum.

[0024] According to this method, a problem with the leak of characteristic information will not occur since a party to prove the possession of right and qualification has no characteristic information.

[0025] However, with the first method, a verifier must hold a list of holders of right and qualification. This imposes the burden of storing and managing the list on the verifier, entailing a high-performance verification device. Also, since the verification device cannot be manufactured independently of the grantor of rights and qualifications, information must be exchanged at all times between the verification device and the grantor of rights and qualifications. Furthermore, since the verifier has individuals' characteristic information, individuals authenticated by this method will have a risk of the characteristic information being illegally leaked by the verifier.

[0026] With the second method, a verifier must hold a list of holders of rights and qualifications. This imposes the burden of storing and managing the list on the verifier, entailing a high-performance verification device. Also, since the verification device cannot be manufactured independently of the grantor of rights and qualifications, information must be exchanged at all times between the verification device and the grantor of rights and qualifications.

[0027] With the third method, since distributed signature information can be used by anyone, its duplication must be prevented. This is achieved by a method of preventing duplicate use of a signature value. To be specific, all signature values once used for authentication are stored in the verifier so that the verifier can check that they are not duplicately used. However, to provide this function for the verifier entails a high-performance verification device. Also, all verification devices to authenticate the same rights and qualifications must share a list of signature values once used for authentication, and therefore information must be exchanged at all times among the verification devices.

[0028] As described above, any of the three conventional methods contains a serious problem, making it difficult to configure particularly a verifier with small-scale devices and software.

[0029] On the other hand, the above-mentioned authentication method that uses characteristic information indicating rights and qualifications is advantageous in that the only task to be done by a verifier is to check to see whether characteristic information indicating rights and qualifications is held.

[0030] As described above, the prior art has been a problem in that if a small-scale verification device is used to authenticate rights and qualifications, there may arise a risk of authentication characteristic information leaking to outsiders, while if the risk is to be eliminated, the verification device becomes large-scale.

[0031] As described above, an object of the present invention is to implement an authentication code technique which enables a small-scale verification device to authenticate rights and qualifications without authentication characteristic information leaking to outsiders.

[0032] An authentication code technique of the present invention is based on:

[0033] (1) an interaction device that generates document private information from a document, which is releasable information defined at ticket issuance, and makes interaction based on the document private information, and

[0034] (2) a ticket, which is releasable information generated from the document private information and authentication characteristic information.

[0035] That is, according to the present invention, where p is a prime number, F_pis a p-element field, G is a finite Abelian group (described multiplicatively only for the purpose of fixing a notation. The present invention can also apply to groups customarily described additively, e.g., an elliptic curve, if it is difficult in point of computational complexity to obtain an annihilator) whose annihilator is difficult in point of computational complexity to obtain, R is a space of commitments, π is a mapping from G to R, and C is a space of challenges, S is a space of messages, φ is a mapping from a set-theoretic product C×S of C and S into F_p, the following steps are executed in an interaction method by which commitment r is generated, and response σ and message M are generated for document m and challenge χ.

[0036] (a) Step to generate nonreproducible private information kεG at random

[0037] (b) Step to compute commitment r=π (k^p)

[0038] (c) Step to compute document private information μ=f (m) with f as a private function with valued in G

[0039] (d) Step to generate message M

[0040] (e) Step to compute exponent C=φ(χ,M)

[0041] (f) Step to compute response σ=kμ^C

[0042] In this configuration, proof functions based on authentication characteristic information can be distributed without disclosing the authentication characteristic information in public key cryptography. Hence, it has become possible for a plurality of individuals having no interest with each other to safely perform proving based on identical authentication characteristic information. This has been heretofore impossible. Since public key cryptography based on Guillou-Quisquater authentication is employed, zero knowledgability is proved. Moreover, messages can be safely transferred.

[0043] FIG. 1 shows the principle of an authentication method of the prior art.

[0044] FIG. 2 shows an overall configuration.

[0045] FIG. 3 shows the configuration of an interaction device.

[0046] FIG. 4 shows the operation of :an interaction device.

[0047] FIG. 5 shows the configuration of a ticket issuance device.

[0048] FIG. 6 shows the operation of a ticket issuance device.

[0049] FIG. 7 shows the operation of a ticket verification device.

[0050] FIG. 8 shows the configuration of an interaction device.

[0051] FIG. 9 shows the configuration of a ticket verification device.

[0052] FIG. 10 shows the operation of an interaction device.

[0053] FIG. 11 shows the principle of a proving method by use of ticket.

[0054] FIG. 12 shows the configuration of an application example.

[0055] FIG. 13 shows the configuration of an application example.

[0056] Prior to the description of embodiments, the usage mode of the present invention will be described briefly.

[0057] FIG. 2 shows the configuration, of the overall configuration of the present invention.

[0058] A ticket issuer issues an interaction device 300 characterized by a specific private function and distributes it to users. If the private function characterizing the interaction device, 300 were known to the users, the interaction device 300 could be freely duplicated and tickets could be abused beyond control of the ticket issuer. Accordingly, the private function of the interaction device 300 can be protected against even authorized holders of the interaction device 300 trying to steal it.

[0059] The interaction device 300 may also be configured, e.g., as a smart card (IC card).

[0060] The interaction device 300, when data m called a document is input, generates document private information μ using a private function f specific to the interaction device 300, and performs interaction based on the document private information.

[0061] Interaction is performed in the following processes:

[0062] (1) output of commitment r

[0063] (2) input of challenge χ

[0064] (3) output of message M and responses σ

[0065] The above interaction is nominally the same as that performed by provers in Guillou-Quisquater authentication. FIG. 1 shows the flow of Guillou-Quisquater authentication.

[0066] Documents are not only used to generate document private information. For example, documents can be programs and commands executable by the interaction device 300, and parameters for processing performed in or messages issued from the interaction device 300 to the prover 200 and to the verifier 100.

[0067] The issuance of ticket t by a ticket issuer in association with authentication characteristic information x is implemented by distributing a function to generate interaction (r, χ, M, s) based on authentication characteristic information to a user by a method described below.

[0068] The ticket issuer uses the ticket issuance device 400 to compute document private information μ from a private function f of the interaction device 300 owned by the user and document m to be transferred to the interaction device when generating interaction, and issues ticket t generated from the authentication characteristic information x and the document private information μ to the user.

[0069] The authentication characteristic information x and the document private information μ are hidden from the user.

[0070] The user generates interaction (r, χ, M, σ) by inputting the specified document m to the interaction device 300 and uses the issued ticket t to transform the interaction (r, χ, M, σ) into interaction (r, χ, M, s) based on authentication characteristic information associated with the ticket.

[0071] When commands of processing for the interaction device 300 are described in the document, interaction generation using a ticket is associated with the commands described in the document, whereby the effectivity of the ticket can be conditioned.

[0072] To be specific, interaction can be transformed by computing response s from challenge χ, response σ of the interaction device, message M, and ticket t.

[0073] It will be described in an embodiment that the transformed interaction (r, χ, M, s)is nothing but an interaction generated by a prover of Guillou-Quisquater authentication in FIG. 1.

[0074] Characteristic information x of authentication associated with the ticket is generated independently of document private information μ that is different for each of various documents of each interaction device 300.

[0075] A ticket issuer can distribute a function of interaction based on given authentication characteristic information x to users in the form of ticket in association with an arbitrary document without disclosing the authentication characteristic information itself.

[0076] [Embodiment]

[0077] [Basic Components]

[0078] In the present invention, [Expression 3]

[0079] the following are cryptographic basic components:

[0080] p prime number

[0081] F_pthe finite field of p-elements

[0082] G Abelian group whose annihilator is difficult in point of computational complex to determine

[0083] D space of commitments

[0084] π Mapping from G to D

[0085] Mathematical concepts referred to hereinafter without being explained will not be explained herein because all of them are fundamental. Refer to Encyclopedic Dictionary of Mathematics (Third Edition) edited by Mathematical Society of Japan, published by Iwanami Shoten, Publishers, for example.

[0086] Generally, an annihilator Ann(G) of Abelian group G, if the operation of the group is described multiplicatively, is an ideal of a rational integer ring Z defined by

[0087] Ann(G)={λεZ;∀gεG)g^t=1}  [Expression 4]

[0088] and since the rational integer ring is a principal ideal domain, the above expression could be written as Ann(G)=λZ by a generating element λε of Ann(G), where λZ is all multiples of λ. Determining an annihilator means finding a generating element λεZ of Ann(G).

[0089] Letting nεZ be a composite number and G be a multiplicative group (Z/nZ)* of a residue class ring of a rational integers, modulo n, λ=λ(n) is established, where λ(n) is a Carmichael function of n, and when n is a power of 2, the following expression is satisfied:

[0090] [Expression 5] $\lambda \left(n\right)=\{\begin{array}{cc}1& n=2\\ 2& n=4\\ n/4& n\notin \left\{2,4\right\}\end{array}$

[0091] When n is a power of an odd prime p, λ(n)=n(1−p⁻¹) is satisfied, and if n=Πp^eprepresents factorization of general n into prime factors, λ(n) is the least common multiple of λ(p^ep).

[0092] Accordingly, if factorization of n into prime factors is already known, since the annihilator of G can be obtained by polynomial time of log n, and conversely, if the generating element λ of annihilator area is already known, by generating a non trivial square root of 1, that is, g satisfying the following expression,

[0093] gεG;g∉{1,−1};g²=1  [Expression 6]

[0094] since n can be factored into prime factors by probabilistic polynomial time of log n, an annihilator determination problem in this case can be expected to be as difficult as a prime factor factorization problem in point of computational complexity. Letting p₁and p₂be mutually different odd prime numbers satisfying p₁≣p₂≣2 mod 3, n be equal to p₁p₂, b be an integer prime to n, E be an Abelian scheme defined on Z/nZ by a homogeneous equation,

[0095] Y²=X³+bZ³  [Expression 7]

[0096] that is, satisfy

[0097] E=Proj Z/nZ[X,Y,Z]/(Y²Z−X³−bZ³),  [Expression 8]

[0098] and G be a finite group E(Z/nZ) consisting of Z/nZ value points of E, then λ is the least common multiple of p₁+1 and p₂+1, in which case the annihilator area determination problem can also be expected to be difficult in point of computational complexity.

[0099] π may be defined as, e.g., an identity mapping id:G→G or as h:G→D using a hash function h.

[0100] A hash function is a function from which it is expected to be difficult in point of computational complexity to find mutually different m and m′ satisfying h(m)=h(m′); for example, MD5 by RSA Data Security Inc. and SHS (Secure Hash Standard) by the U.S. Federal Government are well known.

[0101] When π is an identity mapping the cost of computing π is unnecessary. When π is a hash function and the bit length required to express the element of D is smaller than the bit length required to express the element of G, this produces the effect of reducing traffic.

[0102] For example, for a composite number n of about 1024 bits that is difficult to factor into prime factors, if SHS is used as π letting G=(Z/nZ)*, the size of commitment r can be compressed down to 160 bits.

[0103] By the way, the bit length of p can be no more than 40 bits for authentication of question-and-answer type and no more than 160 bits for signature, accounting for fast Guillou-Quisquater authentication.

[0104] [Interaction Device]

[0105] FIG. 3 shows the configuration of an interaction device 300. The interaction device 300 is mounted as a tamperproof container and is characterized by a specific private function before being distributed to users. The interaction device 300 can also be configured as a portable compact computation device such as a smart card. The interaction device 300 comprises an input-output unit 301, a memory unit 302, a document processing unit 303, a random number generation unit 304, a G algorithm execution unit 305, a π computation unit 306, an f computation unit 307, a φ computation unit 308, and a message generation unit 309.

[0106] FIG. 4 shows the operation of the interaction device 300. Hereinafter, the operation of the interaction 300 will be described.

[0107] Step [1] Generate nonreproducible private information kεG using the random number generation unit 304 and store it in memory unit 302.

[0108] Step [2] Use the algorithm unit 305 in G and the π computation unit 306 to compute commitment r from the nonreproducible private information k stored in the memory unit 302 by the following expression and store it in the memory unit 302:

[0109] r=π(k^p).  [Expression 9]

[0110] Of course, when π is an identity mapping, the π computation unit 306 is unnecessary.

[0111] Step [3] Use the input-output unit 301 to output the commitment r stored in the memory unit 302.

[0112] Step [4] Use the input-output unit 301 to input challenge χ and store it in the memory unit 302.

[0113] Step [5] Use the input-output unit 301 to input document m and store it in the memory unit 302.

[0114] Step [6] Use the document processing unit 303 and perform processing suitable for the document m stored in the memory unit 302.

[0115] Step [7] Use the computation unit 307 for a private function f specific to the interaction device to compute document private information μεG from the document m stored in the memory unit 302 by the following expression and store the result in the memory unit 302:

[0116] μ=f(m).  [Expression 10]

[0117] The computation unit 307 of the function f may be comprised of, e.g., the memory unit 302 for storing private information d specific to the interaction device and the computation unit of the hash function h to compute

[0118] f(m)=h(d|m),  [Expression 11]

[0119] where “|” denotes the concatenation of bits.

[0120] Step [8] Use the message generation unit 309 to generate message M and store it in the memory unit 302.

[0121] Step [9] Use the φ computation unit 308 to compute exponent C from the challenge χ and message M stored in the memory unit 302 by the following expression and store the result in the memory unit 302:

[0122] C=φ(χ,M).  [Expression 12]

[0123] Step [10] Use the algorithm execution unit 305 in G to compute response σ from the nonreproducible private information k, document private information μ, and exponent C stored in the memory unit 302 by the following expression and store the result in the memory unit 302:

[0124] σ=kμ^C.  [Expression 13]

[0125] Step [11] Use the input-output unit 301 to output the message M and response σ stored in the memory unit 302. Step [6] is not always required depending on the application. Accordingly, the interaction device 300 could also be configured without having the document processing unit 303. By providing the document processing unit 303, processing of the interaction device 300 can be changed for each interaction and a ticket described later can be provided with numerous functions.

[0126] [Constraints of Operation Execution Order]

[0127] Steps 1 to 11 need not always be performed sequentially in this order. When the order relation that step “a” must be executed before step “b” is represented by

[0128] a→b,  [Expression 14]

[0129] constraints of the execution order of the steps will be described.

[0130] 1→2→3→4

[0131] 5→6,7

[0132] 4,8→9

[0133] 7,9→10→11  [Expression 15]

[0134] is a constraint on execution order that must always be satisfied.

[0135] When the operation of the document processing unit 303 influences other operations, a constraint of execution order will further arise as described below.

[0136] [When G, p, and π are Variable]

[0137] When the document m defines G, 6→2 is requested. This is true of a case where the interaction device is configured so that parameters defining G are described in document m, the parameters are specified in step [6], and the algorithm execution unit in G can perform computations according to the specified parameters.

[0138] When the document m defines p, 6→2 is requested. This is true of a case where the interaction device is configured so that parameters defining p are described in document m, the parameters are specified in step [6], and the algorithm execution unit in G can perform computations according to the specified parameters.

[0139] When the document m defines π, 6→2 is requested. This is true of a case where the interaction device is configured so that parameters defining G are described in the document m, the parameters are specified in step [6], and the π computation unit can perform computations according to the specified parameters.

[0140] In these examples, although G, p, and π can be changed for each interaction, these can also be constructionally fixed.

[0141] [Prior Execution of Power Computation]

[0142] Herein, G, p, and π are assumed to be fixed.

[0143] If a plurality of sets (k, r) of nonreproducible private information and commitment can be stored in the memory unit 302, since prior repeated executions of steps [1] and [2] in this order eliminate the need to generate commitment r immediately before challenge χ is input, the interaction device requires less time for interaction.

[0144] The only portion specific to each interaction device is a private function f and therefore the portion of generating commitment r can be separated and shared.

[0145] FIG. 8 shows the configuration of an interaction device from which a power computation unit is separated. In this configuration example, the interaction device 300 is divided into a response generation unlit 310 and a commitment generation unit 311, and steps [1] and [2] are performed in the commitment generation unit 311. In FIG. 8, locations corresponding to FIG. 3 ares assigned the corresponding reference numerals.

[0146] Nonreproducible private information k is transferred from the commitment generation unit 311 to the response generation unit 310 by private communication.

[0147] The response generation unit may also be configured as a smart card.

[0148] [When Conditions of Response Generation are Variable]

[0149] When the document m defines conditions for response generation, the conditions for response generation are specified in the document m and processing is stopped if the conditions are not satisfied in step [6].

[0150] Specific examples of processing in accordance with the document m will be described.

[0151] For example, conditions of challenge χ to permit the generation of response are specified in the document m, and if the challenge χ stored in the information memory unit 302 does not satisfy the conditions in step [6], the interaction device 300 stops processing.

[0152] Examples of conditions of challenge to permit the generation of response will be described. A parameter for defining the expiration date of response generation is specified in the document m, a specific bit field when challenge χ is expressed as a bit string is regarded as the expression of current time, the expiration date and the current time are compared, and the interaction device 300 stops processing if the expiration date has elapsed.

[0153] For example, the document processing unit 303 has a clocking unit to hold current time, a parameter for defining the expiration date of response generation is specified in the document m, the expiration date and current time are compared in step [6], and the interaction device 300 stops processing if the expiration date has elapsed.

[0154] For example, the document processing unit 303 has a counter, a flag to define whether to decrement the value of the counter is specified in the document m, and when the flag indicates decrement operation in step [6], if a counter value is not 0, the counter value is decremented by 1; if 0, the interaction device 300 stops processing.

[0155] For example, the document processing unit 303 has a counter, a value by which to decrement the counter is specified in the document m, and if the counter value is not smaller than the value to decrement in step [6], the counter value is decremented by the specified value; otherwise, the interaction device 300 stops processing.

[0156] For example, the document processing unit 303 has a plurality of counters, pointers to define corresponding counters are specified in the document m, and if the value of the defined counter is not 0 in step [6], the counter value is decremented by 1; if 0, the interaction device 300 stops processing.

[0157] For example, the document processing unit 303 has a plurality of counters, pointers to define corresponding counters and a value to decrement are specified in the document m, and if the value of the defined counter is not smaller than the value to decrement in step [6], the counter value is decremented by the specified value; otherwise, the interaction device 300 stops processing.

[0158] [When a Method of Generating Messages is Defined in a Document]

[0159] The document m defines a method of generating messages. This is true of a case where parameters for defining message generation are described in the document m, the parameters are specified in step [6], and the message generation unit 309 generates messages according to the specified parameters.

[0160] Specific examples of processing in accordance with the document m will be described.

[0161] The simplest case is found when a message M is determined as a function of the document m. For example, a specific bit field in the document m is used as a message M.

[0162] For example, conditions of challenge χ to permit the generation of response are specified in the document m, and if the challenge χ stored in the information memory unit 302 does not satisfy the conditions step [6], the interaction device 300 stops processing.

[0163] Examples of conditions of challenge to permit the generation of response will be described. A parameter for defining the expiration date of response generation is specified in the document m, a specific bit field when challenge χ is expressed as a bit string is regarded as the expression of current time, the expiration date and the current time are compared, and the interaction device 300 stops processing if the expiration date has elapsed.

[0164] For example, the document processing unit 303 has a clocking unit to hold current time, a parameter for defining the expiration date of response generation is specified in the document m, the expiration date and current time are compared in step [6], and the interaction device 300 stops processing if the expiration date has elapsed.

[0165] For example, the document processing unit 303 has a counter, a flag to define whether to decrement the value of the counter is specified in the document m, and when the flag indicates decrement operation in step [6], if a counter value is not 0, the counter value is decremented by 1 and a flag (indicating whether the decrement operation has succeeded or not) stored in the message generation unit 309 is turned on; if the counter value is 0, the flag stored in the message generation unit 309 is turned off, and the message generation unit 309 generates a message as a set of the counter value and a flag value indicating whether the decrement operation has succeeded.

[0166] For example, the document processing unit 303 has a counter, a value by which to decrement the counter is specified in the document m, and if the counter value is not smaller than the value to decrement in step [6], the counter value is decremented by the specified value, the flag (indicating whether the decrement operation has succeeded or not) stored in the message generation unit 309 is turned on; if the counter value is smaller than the value to decrement, the flag stored in the message generation unit 309 is turned off, and the message generation unit 309 generates a message as a set of the counter value and a flag value indicating whether the decrement operation has succeeded.

[0167] For example, the document processing unit 303 has a plurality of counters, pointers to define corresponding counters are specified in the document m, and if the value of the defined counter is not 0 in step [6], the counter value is decremented by 1 and the flag stored in the message generation unit 309 is turned on; if the value of the defined counter is 0, the flag stored in the message generation unit 309 is turned off and the message generation unit 309 generates a message as a set of the value of the defined counter and the flag value.

[0168] For example, the document processing unit 303 has a plurality of counters, pointers to define corresponding counters and a value to decrement are specified in the document m, and if the value of the defined counter is not smaller than the value to decrement in step [6], the counter value is decremented by the specified value and the flag stored in the message generation unit 309 is turned on; if the value of the defined counter is smaller than the value to decrement, the flag stored in the message generation unit 309 is turned off and the message generation unit 309 generates a message as a set of the value of the defined counter and the flag value.

[0169] [Document Processing and Other Examples]

[0170] For example, the document processing unit 303 has a counter, a value to increment is specified in the document m, and the counter value is incremented by the specified value in step [6].

[0171] For example, the document processing unit 303 has a plurality of counters, pointers to define corresponding counters and a value to increment are specified in the document m, and the value of the defined counter is incremented by the specified value in step [6].

[0172] For example, the document processing unit 303 has a clocking unit to hold current time and a unit to hold history information, a flag to define whether to record history is specified in the document m, and if the flag indicates the recording of history, a tuple of the current time stored in the clocking unit and the document m is stored in the history memory unit.

[0173] [Batch Processing of a Plurality of Documents]

[0174] In the examples described above, only one document m is involved in one interaction, but a construction can also be made so that a plurality of documents m₁. . . , m_Ncan be involved.

[0175] FIG. 10 shows the operation of an interaction device that performs batch processing for a plurality of documents.

[0176] When a plurality of documents is to be handled in one interaction, steps [5] to [7] have to be replaced by the following steps [10] to [12].

[0177] Step [10] Use the input-output unit 301 to input documents m₁, . . . , m_Nand store them in the memory unit 302.

[0178] Step [11] Use the document processing unit 303 and perform processing sequentially in accordance with the documents m₁, . . . , m_Nstored in the memory unit 302.

[0179] Step [12] Use the computation unit 307 of a private function f specific to the interaction device to compute document private information μεG from the documents m₁, . . . , m_Nstored in the memory unit 302 by the following expression and store it in the memory unit 302.

[0180] μ=f(m₁. . . f(m_N).  [Expression 16]

[0181] Of course, when a plurality of documents are to be handled in one interaction, care must be taken so that there is no conflict among the execution results of processing for each document m_i.

[0182] [Ticket Issuance Device]

[0183] The ticket issuance device 400 uses the following authentication information I and authentication characteristic information x.

[0184] IεGVerification information  [Expression 17]

[0185] xεG Authentication characteristic information where authentication characteristic information x and verification information I satisfy the following relation:

[0186] Ix^p=1.

[0187] Assume that the generator λ of an annihilator Ann (G) is known. If p is prime to λ, since d satisfying

[0188] pd=1 mod λ  [Expression 18]

[0189] can be computed, for any verification information I, corresponding authentication characteristic information x can be obtained as

[0190] x=I^−d.  [Expression 19]

[0191] Also, when p=2, if n is a Blum number in G=(Z/nZ)*, I can be defined almost arbitrarily. For details, refer to “How to prove yourself: practical solutions to identification and signature problems”, Advances in Cryptography CRYPTO '86 (Lecture Notes in Computer Science v. 263), A. M. Odlyzko (ed.), Springer-Verlag, pp. 186-194 by Fiat and Shamir.

[0192] FIG. 5 shows the configuration of a ticket issuance device and FIG. 6 shows the operation of the ticket issuance device. The ticket issuance device 400 comprises an input-output unit 401, a memory unit 402, a G algorithm execution unit 403, and an f computation unit 404. Hereinafter, the operation of the ticket issuance device 400 will be described.

[0193] [1] Use the input-output unit 401 to input authentication characteristic information x and store it in the memory unit 402.

[0194] [2] Use the input-output unit 401 to input document m and store it in the memory unit 402.

[0195] [3] Use the input-output unit 401 to input the identifier U of the interaction device 300 and store it in the memory unit 402.

[0196] [4] Use the computation unit 404 of a private function f specific to an interaction device 300 corresponding to the identifier U stored in the memory unit 402 to compute document private information μ from the document m stored in the memory unit 402 by the following expression and store the result in the memory unit 402:

[0197] μ=f(m).  [Expression 20]

[0198] [5] Use the algorithm execution unit/403 in G to compute ticket t from the authentication characteristic information x and document private information μ stored in the memory unit 402 by the following expression and store the result in the memory unit 402:

[0199] t=xμ⁻¹.  [Expression 21]

[0200] [6] Use the input-output unit 401 to output the ticket t stored in the memory unit 402.

[0201] The private function f specific to the interaction device 300, for example, as described in the section of an interaction device, may also be computed as f(m)=h(d|m) using private information d specific to the interaction device 300 and a hash function h.

[0202] The private information d specific to the interaction device 300 may also be generated at random by, e.g., a ticket issuer so that a tuple (U,d) with the identifier U of the interaction device is stored.

[0203] Using private information D of a ticket issuer, the private information d specific to the interaction device 300 may also be generated to satisfy the following expression where U is the identifier of the interaction device 300:

[0204] d=U|D.  [Expression 22]

[0205] However, generating d in this manner has the problem that the private information D of the ticket issuer may leak when the tamper-proof capability of the interaction device collapses.

[0206] It is more desirable that a hash function h is used to generate d as

[0207] d=h(U|D)  [Expression 23]

[0208] because the interaction device 300 need not hold D and it is difficult to obtain D from d because of the one-way nature of the hash function.

[0209] The document m can afford any values that can become input values of the private function f.

[0210] Further, the document m may also describe processing to be performed by the document processing unit 303 of the interaction device 300 as described in the section of an interaction device.

[0211] Further, the document m may also describe information to identify tickets.

[0212] For example, a provider's identifier, the identifier of service provided by a ticket, a sequential ID assigned in the order of ticket issuance may also be included in the document m.

[0213] A ticket issuer, for example, can also manage authentication characteristic information x and an identifier thereof to include the identifier in the document m.

[0214] For example, values determined from public information I corresponding to authentication characteristic information x may also be included.

[0215] [Method of Synthesizing Ticket]

[0216] Here, let G, p, and π be common to the system and the interaction device 300 correspond to a plurality of documents.

[0217] Let t₁, . . . ,t_NεG be tickets generated for the interaction device 300 having a specific private function f and I_iεG be verification information corresponding to each ticket t_iwhen 1≦i≦N.

[0218] A synthesized ticket t corresponding to synthesized verification information I=I₁. . . I_Ncan be generated as the following expression.

[0219] t=t₁. . . t_N.  [Expression 24]

[0220] Document m_icorresponds to ticket t_iand authentication characteristic information x_icorresponds to verification information I_i. That is, letting I_ix_i^p=1, since document private information μ_i=f(m_i) is

[0221] μ_i=t_i⁻¹x_i,  [Expression 25]

[0222] letting x=x₁. . . x_N, x is authentication characteristic information corresponding to synthesized verification information I, that is, Ix^p=1, and document private information μ=f(m₁) . . . f(m_N) satisfies the following expression.

[0223] μ=t⁻¹x.  [Expression 26]

[0224] [Proof Method by use of Ticket]

[0225] FIG. 11 shows the operation of a proof method by use of ticket.

[0226] Hereinafter, a description will be made of a proof method by use of ticket and an interaction device.

[0227] Assume that a user has an interaction device characterized by a private function f, and document m and ticket t that satisfy t=xf(m)⁻¹.

[0228] Commitment r, and message M and response s for challenge χ are generated in a way described below.

[0229] [1] Use the interaction device 300 to obtain commitment r.

[0230] [2] Use the interaction device 300 to obtain message M and response a corresponding to document m and challenge χ.

[0231] [3] Compute exponent C from challenge χ and obtained message M by the expression C=φ(χ,M).

[0232] [4] Compute response s from ticket t, exponent C, and obtained response σ by the following expression.

[0233] s=t^Cσ.  [Expression 27]

[0234] At this time, (r,χ,M,s) satisfies the following expression.

[0235] r=π(s^pI^φ(χ,M).  [Expression 28]

[0236] In this way, without telling the user the authentication characteristic information x, by using the interaction device 300 and ticket t, a prover function shown in FIG. 1 for verification information I can be distributed.

[0237] Since a verifier corresponding to the prover is exactly the same as that in the conventional example shown in FIG. 1, the verification device needs only the verification information I, so that a great number of users can be authenticated simply with an extremely small device. [Flat-Shamir authentication]

[0238] Particularly when p=2,

[0239] r=π(s²I^C)  [Expression 29]

[0240] is satisfied; the relationship of so-called Fiat-Shamir authentication is satisfied.

[0241] In this way, without telling the user the private information x, by using an interaction device and ticket t, the prover function of Fiat-Shamir authentication for verification information I can be distributed.

[0242] For details of Fiat-Shamir authentication, refer to “How to prove yourself: practical solutions to identification and signature problems”.

[0243] [Guillou-Quisquater Authentication]

[0244] Particularly, when p is prime to the generator χ of an annihilator of G, it means that a user has behaved as a prover of Guillou-Quisquater authentication.

[0245] In this way, without telling the user the private information x, by using an interaction device and ticket t, the prover function of Fiat-Shamir authentication for verification information I can be distributed.

[0246] [Ticket Verification device]

[0247] FIG. 9 shows the configuration of a ticket verification device and FIG. 7 shows the operation of a ticket verification device.

[0248] A ticket verification device verifies tickets by interacting with an interaction device. The ticket verification device 500 comprises an input-output unit 501, a memory unit 502, a random number generation unit 503, a G algorithm execution unit 504, a π computation unit 505, and a φ computation unit 506.

[0249] Hereinafter, the operation of the ticket verification device 500 will be described.

[0250] The ticket verification device 500 stores verification information I and ticket t in the memory unit 502.

[0251] [1] Use the input-output unit 501 to input commitment r and store it in the memory unit 502.

[0252] [2] Use the random number generation unit 503 to generate challenge χ and store it in the memory unit 502.

[0253] [3] Use the input-output unit 501 to output the challenge x stored in the memory unit 502.

[0254] [4] Use the input-output unit 501 to input message M and response σ and store it in the memory unit 502.

[0255] [5] Use the φ computation unit 506 to compute exponent C from the challenge χ and message M stored in the memory unit 502 as C=φ(χ,M), and store the result in the memory unit 502.

[0256] [6] Use the algorithm execution unit 504 in G, and if necessary the π computation unit 505 to compute

[0257] r′=π((t^cσ)^pI^C)  [Expression 30]

[0258] from C, σ, I, and ticket t stored in the memory unit 502, and store the results in the memory unit 502.

[0259] If π is an identity mapping, the π computation unit is not required.

[0260] r′ may be computed as e.g., r′=π((t^pI)^Cσ^p).

[0261] [7] Compare r with r′ stored in the memory unit 502.

[0262] If ticket t corresponds to document private information μ and authentication characteristic information x,

[0263] μ=t⁻¹x  [Expression 31]

[0264] is satisfied and, in interaction based on document private information μ, (r,χ,M,σ) satisfies

[0265] r=k.

[0266] and

[0267] σ=kμ^φ(χ,M).  [Expression 32]

[0268] Accordingly, in interaction between the interaction device 300 satisfying μ=f(m) where f is a private function, and the verification device 500, r=r′ is satisfied.

[0269] [For a Variable Number of Tickets]

[0270] Herein, a description will be made of a configuration in which tickets are input to the input-output unit 501 and the input tickets are stored in the ticket memory unit 502.

[0271] Prior to steps [1] to [6], the ticket verification device 500 performs the steps described below.

[0272] [8] Use the input-output unit 501 to input ticket t and store it in the memory unit 502.

[0273] This configuration permits verification of a plurality of tickets.

[0274] When space of commitments R and space of challenges C are equal and a function to generate an exponent, which uses a hash function h, satisfies

[0275] φ(χ,M)=h(χ|M),  [Expression 33]

[0276] then, letting challenge χ be commitment r itself, that is, letting χ=r, for interaction succeeding in verification, signature (M,R,s) may be stored as a verification history in the memory unit.

[0277] This configuration makes it possible to prove to a third party that ticket authentication has been surely performed.

[0278] Of course, a verification expression used by the third party to verify signature (M,R,s) is

[0279] r=s^pI^h(r|M).  [Expression 34]

[0280] [Application Example: Membership Card]

[0281] A description will be made of an example of application of the interaction device 300 and the prover function by use of ticket having been heretofore described to actual applicative aspects.

[0282] An example of application to membership cards will be described using FIG. 12. In this application example, authentication characteristic information x is made to correspond with service, a ticket provides a qualification for using the service, and a message transferred during proof contains the service name and an identifier as a service user, that is, a member's ID code.

[0283] A ticket in this application example implements by a bit string a membership card or the like usually implemented by a plastic card or the like.

[0284] A ticket issuer is a service provider and a membership card verification device 1000 is composed of:

[0285] (1) smart card reader 510

[0286] (2) membership number display unit 511

[0287] (3) ticket verification device 500 implemented as a program burnt into a ROM within the smart card reader.

[0288] The display unit 511, when ticket verification succeeds, displays a transferred message, i.e., a member's ID code, and gives an error indication when ticket verification fails.

[0289] The smart card reader 510 has a slot for inserting a smart card to communicate with the smart card.

[0290] Assume that a service user owns a smart card 2000 composed of a ticket memory unit 312, a document memory unit 313, and an interaction device 300.

[0291] The service user, when making member registration, presents the identifier of his interaction device 300 to have a ticket corresponding to the interaction device 300 issued, and inputs it along with a document to the smart card 2000, for example.

[0292] A document is composed of a field to represent a service name (e.g., “Xerox Club”) and a field to represent a member's ID code (e.g., “0017 257 65537”).

[0293] When using the service, the user inserts the smart card 2000 into the membership card verification device 1000 to perform ticket authentication.

[0294] Herein, a construction is made so that messages generated by the interaction device 300 are documents themselves.

[0295] If an input part different from the smart card reader 510 within the membership card verification device 1000 is provided to input tickets and documents, tickets and smart cards need not necessarily be stored in the smart card 2000.

[0296] For example, a user carries a smart card 2000 comprising only an interaction device 300 and may store tickets and documents in portable information equipment different from the smart card 2000 or store them in a home PC to obtain them using portable communication equipment as. required.

[0297] A ticket need not always be issued at the time of member registration; it can also be replaced by a plastic membership card already held by the user.

[0298] A ticket issuer may be provided independently of a service provider so that the service provider commits the issuance of tickets to service users to the independent ticket issuer.

[0299] If a ticket issuer is provided independently, since tickets corresponding to various services can be issued to a single interaction device 300, users can hold a plurality of membership cards and the like exactly only as electronic information if only the users have the only interaction device 300.

[0300] [Application Example: Prepaid Card]

[0301] Next, an example of application to prepaid cards will be described referring to FIG. 13.

[0302] In this application example, authentication characteristic information x is made to correspond with service, a ticket is a prepaid card used for the service, and a message transferred during proving contains information about success or failure of withdrawal from the prepaid card and balance information of the prepaid card.

[0303] A ticket issuer is a service provider and a prepaid card handling device 1500 is composed of:

[0304] (1) smart card reader 510

[0305] (2) withdrawal amount input unit 512

[0306] (3) display unit 513

[0307] (4) PIN input unit 514

[0308] (5) ticket verification device 500 implemented as a program burnt into a ROM within the smart card reader.

[0309] The smart card reader 510 has a slot for inserting a smart card 2000 to communicate with the smart card 2000.

[0310] The withdrawal amount input unit 512, comprised of e.g. ten-keys, is used to input a withdrawal amount.

[0311] The display unit 513 displays a withdrawal amount input in the withdrawal amount input unit 512, then if ticket authentication succeeds, displays a transferred message, that is, information about success or failure of withdrawal and a balance of the prepaid card; otherwise, it gives an error indication.

[0312] The PIN input unit 514, composed of e.g. ten-keys, is used for PIN input by users.

[0313] Assume that a service user owns a smart card 2000 composed of the ticket memory unit 312 and the interaction device 300.

[0314] The service user, when purchasing a prepaid card, presents the identifier of his interaction device 300, PIN to be associated with the prepaid card, and a face value of the prepaid card to have a ticket corresponding to the interaction device 300 issued, and inputs it to e.g. his own smart card 2000 and sets the face value information of the prepaid card in a counter of the interaction device 300.

[0315] A document composed of a field to represent a service name (e.g., “Xerox Store”) and a field to represent PIN (e.g., “0917”).

[0316] When using the service, the user inserts the smart card 2000 into the prepaid card handling device 1500 to perform ticket authentication.

[0317] The smart card reader 510 obtains the ticket stored in the smart card 2000, sets it in the ticket verification device 500, and starts interaction.

[0318] A withdrawal amount (e.g., 350 yen) input in the withdrawal amount input unit 512 is embedded in a specific bit field of a challenge sent from the ticket verification device 500, and a service name (e.g., “Xerox Store”) and PIN (e.g., “0917”) input from the PIN input unit 514 together are input to the interaction device 300 as a document.

[0319] The message generation unit 309 (FIG. 3) of the interaction device 300, if a withdrawal amount embedded in the challenge is not greater than a counter value (e.g., 2000 yen), decrements the counter value by the withdrawal amount (that is, 1650 yen) and generates a withdrawal success indication (“OK”) and a counter balance (1650 yen) as a message. If the withdrawal amount is greater than the counter value, the message generation unit 309, without decrementing the counter, generates a withdrawal failure indication (“NG”) and a counter balance as a message.

[0320] The ticket verification device 500 verifies a sent message, and in the case of withdrawal failure, for example, withdraws only a card balance from the card to have the user pay a differential amount in cash.

[0321] As described hereinbefore, the. present invention can distribute proof functions based on authentication characteristic information without disclosing the authentication characteristic information in public key cryptography. Hence, it has become possible for a plurality of individuals having no interest with each other to safely perform proving based on identical authentication characteristic information. This has been heretofore impossible. This fact makes it possible to associate a ticket not necessarily belonging to individuals in nature with authentication characteristic information in public key cryptography without modification and the verification side of the ticket can perform authentication simply by determining whether the ticket is true or false according to a disclosed procedure based on disclosed unique verification information, so that the burden on the verification side can be remarkably reduced. Also on the part of the user to prove the holding of the ticket, the above-described characteristic of the verification side is advantageous in that the fairness of the verification side can be confirmed and individuals are not located (because authentication characteristic information not belonging to individuals participates in verification) to verify the ticket. Moreover, to the user, a ticket and an interaction device are black boxes understandable only to a ticket issuer, and if the ticket is input to the interaction device, it cannot be assured that a covert channel not concerned in implementing the authentication method does not exist, whereas, in the present invention, information transfer to the interaction device is implemented as a document which permits the user full interpretation but will not impair the safety of the protection side, and a ticket as a black box is not input to an interaction device as a black box.

[0322] The present invention employs Guillou-Quisquater authentication as base public key cryptography. The Guillou-Quisquater authentication is proved by Guillou and Quisquater as to zero knowledgability by “A ‘paradoxical’ identify-based signature scheme resulting from zero-knowledge”, Advances in Cryptology CRYPT '88 (Lecture Notes in Computer Science v. 403), S. Goldwasser (ed.), Springer-Verlag, pp. 216-231 by Guillou and Quisquater.