« PreviousContinue »
RETURNED-VALUE BLIND SIGNATURE
BACKGROUND OF THE INVENTION 5
1. Field of the Invention
This invention relates to transaction systems for value transfer, and more specifically to improved cryptographic techniques involving publickey digital blind signatures in online value transfers. 10
2. Description of Prior Art
Of the many proposed electronic payment systems for consumers, only a few allow consumers to ensure that all their transaction data is not linked together into a file on their activities. This property is anticipated to 15 become important in achieving consumer acceptance of automated payment systems, particularly as consumers become more sophisticated about the issues and as systems become more extensive and pervasive.
The underlying technique for allowing consumers to 20 protect their privacy in electronic payments was disclosed in U.S. Pat. No. 4,759,063, titled "Blind Signature Systems," issued to the present applicant, also appearing as European Patent Publication No. 0139313 dated 2/5/85, and which is incorporated herein by ref- 25 erence. A characteristic of these systems is that the payer withdraws money from an account in the form of digital signatures that are later presented in payments. Thus, some provision is needed to at least discourage payers from spending the same digital signature more 30 than once.
For relatively-low-value payments, this "multiplespending" problem can be addressed by techniques that compromise the privacy of those attempting to show the same signature more than once, as described in the 35 co-pending application of the present applicant, titled "One-Show Blind Signature Systems," filed 3/3/88, with U.S. Ser. No. 168,802, now abandoned.
While such offline techniques may be suitable for a certain segment of payments, the present application is 40 concerned with those other payments requiring the higher security of online verification. For these medium- and higher-value payments, the cost of consulting an online list of already spent digital signatures should be acceptable. 45
An essential difficulty with currently known online systems, however, is that they generally require a separate digital signature for each denomination. It is believed that one of the most efficient denomination schemes is that based on the powers of two: a one cent 50 digital signature, a two cent signature, a four cent signature, an eight cent signature, and so on. To make a payment, the payer would use the appropriate selection of denominations, much as with coins and bank notes today. For amounts in the neighborhood of $10, for 55 instance, even this binary scheme would entail at least 10 different denominations, approximately half of which would be involved in each payment. For larger amounts, the number of denominations grows logarithmically, so that in the $500 range, 16 denominations are 60 needed, and an average of half are still required for uniformly distributed amounts of payment. When interest is to be earned on value held by the payer, fractionalcent amounts can be needed, further increasing the number of denominations that must be handled. 65
Of course all these denominations would take up considerable space in a hand-held computer that might be carried by a consumer to the point of sale. They also
must be communicated to the retailer and relayed to the payment system provider. Moreover, the system provider must store each of the signatures separately and must look all the signatures submitted for a payment up on the list of already accepted numbers, before giving an O.K. to the shop. Thus, multiple denominations expand the storage and communication costs and might cause appreciable delays.
Additionally, there is the problem of what to do when the payer does not happen to have the proper complement of coins to pay the exact amount, but only a larger amount. It appears then that further signatures would have to be exchanged to return the unspent value. This might also raise the concern that the shop should not be able to improperly obtain the change itself. Furthermore, the complement of coins held by a payer, once revealed, could be used to infer other information about the payer. One thing about which something may be deduced is how much money the payer happens to have at the moment. Another thing revealed might be which other payments could have or could not have made by the particular payer, because of the exact coins involved.
OBJECTS OF THE INVENTION
Accordingly, an object of the present invention is to reduce the requirement for storage of numbers representing value. For the payer, this means reducing the amount of storage needed to maintain value stored within the payer's equipment, such as a card computer. For the shop, this means simply reducing the amount of data that must be held temporarily before it is forwarded to the bank. For the bank, it means reducing the storage required for already spent numbers—as well as the number of accesses to this database required during acceptance of a payment.
Another object of the present invention is to reduce the amount of information that must be transmitted: between the payer and shop, as well as between the shop and bank. This in turn can reduce the time and expense of completing a transaction with a given communication technique.
A further object of the invention is to hide from the bank the exact amounts involved in payments made by a payer, and to accomplish this by aggregating the unspent value.
Yet another object of the invention is to hide, both from the shop and from the bank, the total value of the instrument being offered by the payer.
A still further object of the invention is to allow the payer to build new payment instruments from the returned value. These instruments might even be indistinguishable from those directly issued by banks.
Yet a further object of the invention is to prevent a payer from being vulnerable to a shop taking more value (or change) for itself than the payer has agreed.
Still another object of the present invention is to allow efficient, economical, and practical apparatus and methods fulfilling the other objects of the invention.
Other objects, features, and advantages of the present invention will be appreciated when the present description and appended claims are read in conjunction with the drawing figures.
BRIEF DESCRIPTION OF THE DRAWING
FIG. 1 shows a flowchart of a preferred embodiment of a withdrawal transaction protocol for a bank to issue value to a payer in accordance with the teachings of the present invention.
FIG. 2 shows a flowchart of a preferred embodiment of a payment transaction protocol allowing a payer to accumulate returned value in accordance with the teachings of the present invention.
FIG. 3 shows a flowchart of a preferred embodiment of a payment transaction protocol with returned value that can be used in subsequent payments, but with the spendable value known to the shop and bank, in accordance with the teachings of the present invention.
FIG. 4 shows a flowchart of a preferred embodiment of a payment transaction protocol with hidden returned and spendable value, and with returned value useable in subsequent payments, all in accordance with the teachings of the present invention.
FIG. 5 shows a flowchart of a preferred embodiment of a two part payment protocol including signed agreement and a single consummation point, also with hidden returned and spendable value, and with returned value useable in subsequent payments, all in accordance with the teachings of the present invention.
FIG. 6 shows modifications to the flowcharts of the preferred embodiments of FIGS. 2-5 that allow returned value to be divided among multiple subsequent payments in accordance with the teachings of the present invention.
BRIEF SUMMARY OF THE INVENTION
In accordance with these and other objects of the present invention, a brief summary of some exemplary embodiments is presented. Some simplifications and omissions may be made in the following summary, which is intended to highlight and introduce some aspects of the present invention, but not to limit its scope. Detailed descriptions of preferred exemplary embodiments adequate to allow those of ordinary skill in the art to make and use the inventive concepts are provided later.
Each different denomination (i.e. "coin value") is 45 represented by a different public exponent, but all signatures use the same RSA modulus of the bank. A single signature might contain a plurality of denominations; it would thus have a public exponent that is the integer product of the public exponents corresponding to the denominations it contains. This allows a particular denomination to be removed from the set of denominations present in a signature by anyone raising the signature to the public exponent corresponding to the denomination to be removed.
It is assumed, as already mentioned above, that each payment is deposited online. It is also assumed that a payer has a signature containing at least a suitable combination of denominations for making each payment.
First the payer devalues the signature, as explained above, so that it represents the exact amount to be paid. Then this is provided to the bank, via the shop, along with a second number. This second number is "blinded," as explained in the already mentioned U.S. patent titled "Blind Signature Systems." The bank checks that the signature on the first number received contains the appropriate denominations and makes a signature on the second number, which is then returned
to the payer. The payer "unblinds" this second number, as also described in the already mentioned U.S. patent titled "Blind Signature Systems."
Several variations on the inventive concepts disclosed here are provided by exemplary embodiments described in detail later. For example, the embodiment of FIG. 2 can implement a "cookie-jar" scheme in which all the surplus value returned to a payer is accumulated in a single number that is ultimately deposited, such as when the next withdrawal is made. Another example, detailed in FIG. 3, also assumes that the total original value of the signature, which has been devalued for payment, is known to the bank, but provides for the possibility of plural original values. The bank returns the exact amount in a form that allows only someone possessing the original signature having the known original value to recover the returned value. This embodiment (like that of the following figures) also has the ability to readily allow the returned signatures to be used in constructing signatures that can used in payments in a way indistinguishable from originally withdrawn values—thus change can be recycled into money of the same form as that freshly withdrawn from the bank. The embodiment detailed in FIG. 4, extends that of FIG. 3 at least by allowing the original value to be kept secret from the bank and by not requiring extra work to anticipate each value it might have.
The variation detailed in FIG. 5 illustrates several extensions and variations at once. One is that the techniques of FIG. 2 and FIG. 3 can be combined in a single payment. Another is how more secure payments can be carried out in a series of steps that reduce the exposure of the parties at each point. Also achieved is a "safe point" in the transaction process where the payer must provide a single number in exchange for the goods: the payer does not benefit from withholding the number; the payer does not need to rely on the shop to return any further numbers; and the shop can check the number immediately without communicating with the bank. The actual deposit by the shop can be made later at the shop's leisure.
In FIG. 6, some modifications to the embodiments of FIGS. 2-5 are disclosed. They allow the value returned to be divided between two numbers. How the returned value is distributed among the numbers, and even the fact that any such division is taking place, is believed to be perfectly hidden from the shop and bank. Thus, the single blinded number provided by the payer is formed in a way that allows its signed form to be split into two signatures, with the returned value split between them.
The protocols to be described in detail later and the drawing figures make a number of simplifying assumptions for concreteness and for clarity in exposition. It will be appreciated, however, that these should not limit the scope of the invention.
The denomination scheme already described and mentioned again later, for instance, is just one example. Other schemes might use quite different selections of denominations. For example, denomination schemes closely copying those already in use with particular currencies around the world are possible. There might also be redundancies, as with actual currencies that have multiple types of coins or notes for the same denomination. It should also be pointed out that, in some cases, an exponent standing for a lower value denomination might divide a higher valued one. A common factor among plural denomination public exponents might also offer certain advantages. Denominations closer to a single coin type might be used for the lower values, thereby hiding the combinations of amounts more fully. It is even possible, of course, for a single denomination 5 to be used, with multiplicities of the public exponent standing for higher values, such multiplicities being mentioned again later.
The choice of party names, and the number of parties are also examples of choices made for clarity and con- 10 venience. Naturally, the inventive concepts disclosed here should not be interpreted as limited to particular types of parties such as banks, shops, and consumers. They are applicable in any context where value, wether economic or otherwise, is to be transferred between 15 parties. Furthermore, the fact that a shop is shown in between the payer and the bank is just to indicate that such a position could be filled. However, no such party is needed, or more than one can be cascaded. When the payer interacts with the bank directly, no shop party is needed; when the payer interacts with a shop, who interacts with its bank, who interacts with a central bank or bank association—more parties are added into the chain.
DETAILED DESCRIPTION OF PREFERRED
While it is believed that the notation of FIGS. 1-6 would be clear to those of ordinary skill in the art, it is 3Q first reviewed here for definiteness.
The operations performed are grouped together into flowchart boxes. The column that a box is in indicates which party performs the operations defined in that box. The columns are labeled by party name across the 35 top: "P" for payer, "S" for shop, and "B" for bank. Some operations show how messages are formed on the right of the equal sign with the message number (shown in square brackets) on the left of the equal sign. The operation of saving a value under a symbolic name is 40 denoted in the same way as that of forming a message, except that the symbolic name appears on the left instead of a message number.
Another kind of operation is an equality test. The "?=?" symbol is used to indicate these tests, and the 45 party conducting the test terminates the protocol if the equality does not hold. (If the test is the last operation to be performed by a party during a protocol, then the success or failure of the test determines the party's success or failure with the protocol.) 50
A further kind of operation is that of sending a message. This is shown by a message number on the left; followed by a recipient name and an arrow (these appear for readability as either a recipient name then left pointing arrow, when the recipient is on the left; or 55 right pointing arrow then recipient name, when the recipient is on the right); followed by a colon; finally followed by an expression fully denoting the actual value of the message that should be sent, expressed using variables whose values could be unknown to the 60 sender.
The final kind of operation (which can also appear as part of an expression, as described below) is a definition, denoted by expressions separated by ":=". Such notations are included only for clarity and readability and 65 do not indicate actual computations performed; rather, they are a way of indicating the equivalence of certain expressions.
Several kinds of expressions are used. One is just the word "random". This indicates that a value is preferably chosen uniformly from an appropriate set of values, defined in the text, and independently of everything else in the protocol. Thus a party should preferably employ a physical random number generator for these purposes, possibly with appropriate post-processing. In practice, however, well known cryptographic and pseudo-random techniques may be applied, possibly in combination with physical sources. For clarity, explicit restriction on the resulting values may be shown as a predicate following a "|" (read "such that"). The restrictions shown in this way happen to require the GCD of two numbers to be 1, which means that no integer greater than 1 divides both. In some cases, where more than one expression would be appropriate, the choice depending on the particular application and instance of the protocol defined, alternative expressions may be separated by "or".
Other kinds of expressions relate to creating and testing the redundancy used for digital signatures. While there are many suitable redundancy schemes known in the art, and many more that would be obvious to those of skill in the art, a particular notation has been adopted here for clarity in exposition, and should thus not be taken to limit the scope of the present invention. The notation "special" is a variant on "random" described above. It produces values that are unpredictable, to at least some parties, and yet which have a redundancy property. For concreteness, a special number may, for example, be taken to be the concatenation of a random value and its image under a suitable one-way function.
A corresponding monadic predicate, denoted "check" followed by its argument, has the same effects as the equality test mentioned above: if the argument has the redundancy property, then the check behaves as if equality were found; if the argument does not have the property, then the check behaves as if inequality were found. A similar predicate, "search for & record" followed by a single argument, merely looks-up its argument in some suitable data storage system and enters the argument into that system as a side-effect. (These two operations should preferably exclude any similar operation in time, to prevent anything from not being found more than once.) If the argument was not found during the look-up, the effect on the rest of the protocol is the same as that of the case of equality described above; if it was found, then the effect is that of inequality.
A further kind of expression involves exponentiation. All such exponentiation is in a finite group, for example the multiplicative group modulo an RSA modulus, as described later. When no operation is shown explicitly, multiplication in such a group is assumed. When "|" is applied between elements of such a group, the result can be calculated by first computing the multiplicative inverse for the expression on the right and then multiplying the result with the expression on the left—but this may also be called simply a quotient. The results of all such operations on group elements may be assumed for concreteness to be encoded as binary numbers, with the least positive representative, for instance, being suitable when the elements are residue classes. When the "|" is used with integers, such as those serving as exponents, then it denotes integer division if the result is an integer; if the result is a proper fraction, however, it obviously represents a corresponding root, as are well known in the art.
One or more moduli may be used, such as RSA moduli, as are well known in the art, having been first proposed in "A method for obtaining digital signatures and public-key cryptosystems," by Rivest, Shamir and Adleman, Communications of the ACM, Feb. 1978, pp. 5 120-126. For simplicity, concreteness, and clarity, and without loss of generality, all elements will be taken to be residues modulo the RSA modulus of party B, unless mentioned otherwise. The public exponents of party B used in all the figures are taken for simplicity to be the 10 prime divisors of h, each of which is taken to correspond to some denomination. (This is believed to mean that h should be coprime with the order of the group or subgroup used.) For example, a binary denomination scheme may be preferred, where the smallest divisor 15 (say 3) represents 1 cent, the next smallest (say 5) represents 2 cents, the next (say 7) represents 4 cents, and so on, pairing the odd prime exponents with the powers of two—up to the largest divisor of h. Some of these factors are taken to comprise g,g', and g". The integer d (mnemonically representing "denominations paid") is taken to be a divisor of g, thus having a subset of the factors of g. The integer c (mnemonically representing "change returned for overpayment") is a divisor of h, but coprime with g. In FIG. 2, a second modulus of B is preferably also used to separate two different classes of signatures (but the same effect might be obtained by using different sets of exponents, as would be obvious to those of skill in the art). The public exponent of S used 3Q in FIG. 5 is e, which is preferably used with a modulus different from that of B.
The function f is a public one-way function, such functions being well know in the art. It may be assumed to have a domain able to include the result of the largest 35 group operation and a range small enough to be represented in such a group—as well as being suitable for constructing signatures.
Turning now to FIG. 1, the first part of a flowchart for the preferred embodiment will now be described in 4Q detail. It may be thought of as a withdrawal transaction, in which party P withdraws a certain amount of value, represented by g, from party B.
Box 101 shows party P choosing n as a special number, such partly random selection as already mentioned 45 above. Similarly, P also chooses r from the non-trivial residues of B's RSA modulus, uniformly and at random, such random selection also as already mentioned. Then P forms message , as per the notation already described above, by raising r to the power g and multiply- 50 ing the result by n, all in the group of residues. This message  is then sent from P to B. (Note that since the expression of the message clearly shows the method used to construct it, the forming and sending operations have obviously been combined for clarity.) 55
Box 102 indicates that, after receiving message , B first signs it by forming the g'th root, as B can of course do using the factorization of the modulus it created, as is well known in the art. (The value of g is assumed known to both P and B in this protocol, as it will also be 60 in that of FIG. 2 and at least partly in FIG. 3.) Then the result, which has been denoted as message , is sent by B to P. (Notice that the form of this message has been shown for clarity as r times the g'th root of n, as a part of the notation for sending a message, as previously 65 described; this does not, however, as also mentioned above, mean that B can determine the value of r or that ofn.)
Box 103 describes first how the value denoted by symbolic name w (with mnemonic meaning "withdrawal") is calculated by P. The message  received is multiplied by the multiplicative inverse of r, as per the notation described above, to yield w. Finally, P tests w by raising it to the g power and comparing the result for equality with n. If the test is satisfied, P completes the protocol successfully, otherwise not.
Turning now to FIG. 2, the second flowchart for part of the preferred embodiment will now be described in detail. It may be though of as a payment transaction, in which party P gives to S a certain amount of value, represented by d, and receives in return what remains of S
Box 201 begins with P forming message [21.1] as w, from FIG. 1, raised to an integer power. This integer is computed by P as g divided by d. Next, P chooses from one of two alternatives: (1) P sets m to x' from a previous instance of FIGS. 2-5; or (2) P forms m as a special number, much as n was formed in FIG. 1, except it is preferably in a second multiplicative group, i.e. using a different modulus than that which is used in FIG. 1 (or the other figures). Similarly, s is chosen at random, as r was in FIG. 1, but using this same second modulus. The second modulus is preferably chosen by B, who knows its factorization. Two messages are sent by P to B: [21.1], which has already been computed and is the d'th root of n; and [21.2], which is formed as the product of m times s raised to the integer g/d mentioned above, modulo the second modulus.
Box 202 shows that S first raises message [21.1] received from P to the d power under the first modulus and then applies the check predicate to the result. As already mentioned, this predicate will stop the protocol with failure if the redundancy property is not present in its argument. The rest of this box merely shows that S forwards the two messages received, [21.1] and [21.2], on to B as messages [22.1] and [22.2], respectively.
Box 203 is first the checking by B of the message [22.1] received, just as [21.1] was checked by S. Then B searches for n in its storage system. If n is found to be stored, B terminates the protocol with failure; otherwise, B records n in the storage system—as called for by the notation already explained. Then B signs message [22.2] received, by raising it to the fractional power d/g. This could of course be carried out by means widely known in the art, such as, for example, extracting the g'th root and then raising to the d'th power. In any case, this arithmetic should be done over the same group as that in which message [22.2] was originally formed; that is, using the second modulus already mentioned. The result of the signing is message , which has the form m to the d/g times s; this message is shown as sent by B to P, although it could of course also be forwarded by intermediate parties, such as S.
Boxes 204 represents the "unblinding" of message  received by P and its testing. Of course, these could be done in any order, by a variety of means. The particular notation shown first isolates that part of the message that will be referred to later on as x, simply by dividing s out of message  (i.e., forming the quotient, as already mentioned, by first computing the multiplicative inverse of s modulo the second modulus and then multiplying this, modulo the second modulus, by message ). The final testing of the result is shown as raising x to the integer g/d power, and testing the result for equality with m. As mentioned above, the success of