Method for secure payment with micropayment capabilities

0001Patent application title: Method for secure payment with micropayment capabilities Authors: Dr.Tomas Hruz, DrNladimir Botka, Ing.Jan Stary

0002Description

0003Field of the Invention

0004This invention relates to communication network payment schemes which are using public key cryptography and cryptographically secure hash functions for efficient design. In particular, the present invention relates to the field of micropayment technology. The invention can be applied in Internet e-commerce.

0005Background of the Invention

0006Internet economy is recently suffering from large imbalances. There is a high quality software distributed for free, there are flat prices for Internet providing and there is an unsolicited advertisement linked to the most of the valuable content.

0007Possible solution to those problems is lying in a payment system, which should encompass most of the Internet complexity. Notably it must have the following features.

00081. The payment granularity must range from 10^-6 to 10² USD and possibly should be dynamic as well.

00092. The transaction cost of one payment must be cheaper then the payment itself.

00103. The payment method must be secure.

00114. The payment system must be easily applied to all Internet services including the future ones. In particular, it must be able to handle video and other multimedia data streams as well as the telecommunication data streams.

0012We present an efficient solution which has the features mentioned above. In our work we use an idea of payment chain introduced in [1]. However, we use this concept in a novel way to construct a new payment schemes which are the subject of the present invention.

0013Our solution differs from the previous ones (like [1] or [2]) in a crucial conceptual aspect that it is strongly debit oriented avoiding troubles with fraud and double-spending. The solution proposed in [1] is credit oriented. In [2] the authors describe hybrid micropayment system.

0014Contrary to the other solutions which provide approximate or hybrid payments, the presented invention provides an accurate (on line) accounting double entry method where each of the agents immediately know the actual state of their account balance and there is no financial credit involved.

0015We present a method for debit oriented payment schemes allowing fast and simple small payments over the Internet. On the other hand, the method flexibility per transaction is also capable to handle macropayments without any changes as well.

0016At least three agents are involved in the payment operation. There is a vendor who wants to sell any kind of information or goods over the communication network and a customer who is willing to pay for the content. The broker is keeping the accounts for vendors and customers and mediates the payments.

0017In the present invention we understand the notion of an agent in a general way i.e. the agent can be a complex network itself using the same principles of payment data communication as are defined in this invention. Brief description of the Drawings

0018The further defined steps of the method claimed in the present patent are schematically shown in the following drawings:

0019Figure 1 is a schematic diagram of the payment transaction initialization part of the proposed method.

0020Figure 2 is a schematic diagram of the payment transaction method with the most simple payment information included.

0021Figure 3 is a schematic diagram of the payment transaction method with a constant cost for each transaction.

0022Figure 4 is a schematic diagram of the payment transaction method with variable cost for each transaction.

0023Figure 5 is a schematic diagram of the payment transaction method with variable cost for each transaction and "not to pay" possibility for customer.

0024Figure 6 is a schematic diagram of the payment transaction method with variable cost for each transaction and "not to pay" possibility for customer, having a circular dataflow pattern.

0025Description of the Invention

0026In the following we shall denote by small letters v, c, b cryptographically secure sequence of integers generated in the following way.

0027To generate a member of the sequence we use cryptographically strong hash function h such as [3] or [4]. We start with randomly selected first member of the sequence VN. Then we calculate the next members υ_τ-_\ = h(v_τ), for i = N, N — 1, . . . , 1.

0028If the function h is one-way and collision-resistant these features are also conveyed to the sequence defined above. The one-wayness means, that it is a hard problem to calculate the members of the chain in opposite direction; υ_τ+ι = h^~l {v_l), i.e. it is a hard problem to predict the next value in such sequence. The collision-resistance means, that a very large search is needed to find any different inputs υ- and v₃ to produce the same output h(v_l) = h(v₃). This sequence of integers we call a secure chain.

0029We use public-key cryptography (e.g. RSA [5]). The public keys of the broker B, customer C and vendor V are denoted B_pk, C_vk and V_pk- Their secret keys are denoted B_sj-, C_sk, and V_sk- For example, a message M with broker digital signature produced by secret key B_S)- is denoted {M}β_sk - This signature can be verified using the corresponding public key B_pf-.

0030With the symbol (v_Ui , n-)_C] we mean a token where v _i is an element of a secure chain v as described above, n. is the position of v_Ui in the secure chain v starting from VQ. C₃ is an element of another secure chain c, starting from c₀. During the "session" the chain v is transmitting payment data and the chains c or b are used to authorize (secure) the transmition of the payment data over an insecure channel. In the following we use the terms payment chain for v and authorization chain for b and c.

0031We suppose that communicating parties certifies each other in a standard way according to the public key cryptography principles. We denote with Cc the customer certificate and with Cv the vendor certificate.

0032TokenBase

0033With TokenBase we denote a data structure which contains financial value, currency of a token and other attributes describing various financial aspects of the payment. For example, the TokenBase can be defined as follows

0034TokenBase = { currency_type , currency_,.unit { mantisa, exponent }, data_unit { type, time, kByte } > where:

0035TokenBase — >• currency -type is the currency of the token.

0036TokenBase — > currency .unit — mantisa is the mantissa of the financial value of the token.

0037TokenBase — > currency .unit — exponent is the exponent of the financial value of the token.

0038TokenBase — data-unit — type is the type of the payment session.

0039TokenBase -> data unit — time in seconds is the price parameter of the payment session.

0040TokenBase — > datajunit —> kByte in kBytes is the price parameter of the payment session.

0041In this example of data structure the TokenBase — > currency-type and TokenBase - currency-unit determines the price and TokenBase — data-unit determines the amount of goods (information) for the price already mentioned.

0042If for example, currency-type =- USD , currency -unit{mantisa = 1, exponent = —2} and data-unit{type — any, time — 1, kByte — any} then the agent issuing this data structure is submitting an offer to sell or buy a data stream for time of 1 second for the price of 1 cent.

0043If the value of the token is 1 cent then the data structure TokenBase -> data -unit {type, time, kByte} determines the expected behavior of vendor and customer in the session as follows :

0044• data -unit {type = I, time — 1, kByte = 0} means that the customer is required by the vendor to pay 1 cent per 1 second.

0045• data-unit{type = I, time — 0, kByte = 1} means that the customer is required by the vendor to pay 1 cent per 1 kByte of data.

0046• data.unit{type = 2, time = any, kByte = any} means that the customer is required to pay 1 cent on the vendor request.

0047• data unit{type = 3, 4, 5, time — any, kByte = any} means that the value of the token is a multiple of 1 cent and the customer is required to pay on the vendor request. The multiple is determined as the product of 1 cent and the difference between indices j — i of the subsequent members υ- and υ₃ of the payment chain originated by the vendor.

0048Session

0049We use the notion of session or payment session in the following meaning. The session is a relation among the agents. The session starts with an initialization phase and proceeds with the payment transactions. Each transaction describes a transfer of a particular amount of money.

0050Session initialization scheme

0051Scheme protocol:

00521. C — >^■ V : request

0053The initialization of the "session" is started on the C request to V in any detectable form.

00542. V → C : C_υ, {vo, TokenBase}v_sk

0055V calculates the payment chain v_τ where i = N, N — 1, . . . , 0 then sends to C her certificate C_v, the first member of the V secure chain υo and price information TokenBase. The values VQ and TokenBase are signed by the V. The certificate C_υ does not have to be signed. 3. C → B : C_c, {c₀, C_v, {v₀, TokenBase}v_3k}c_3k

0056C calculates the authorization chain c- where i = N, N — 1, . . . , 0 then sends to B her certificate C_c, the first member of the C secure chain c₀ and all information she received from V in the previous step. The values received from V and c₀ are signed by the C. The certificate C_c does not have to be signed.

00574. B → V : {vo, b₀}_Bsk

0058B calculates the authorization chain b_τ where i = N, N — 1, . . . , 0 then sends to V the first member of the V payment chain VQ and the first member of the B authorization chain 6r The values VQ and ₀ are signed by the B.

0059The length of the authorization chains c and b does not have to be necessarily equal to the length of the payment chain υ. If any agent in the session use her authorization chain up to the end, then she must calculate a new one and submit the first member c₀ or bς, of the chain to the next agent in a secure way using public-key cryptography. It is a responsibility of V that she prepares the payment chain long enough for the whole session. If V use the payment chain up to the end, she must finish the session and start the initialization of new session.

0060The continuation of the payment session depends on the payment properties expressed in the TokenBase items negotiated during the initialization phase. In the following we describe the design of five different payment schemes that comprise payment transactions with different properties.

0061In the following description of the schemes we use a unified structure. First, we describe scheme protocol, then broker money account transfer decisions, scheme properties and application example. In the schemes we denote the financial value of the token as currency -unit.

0062Scheme 1.

0063Customer is paying fix price per time or data amount. The payment transaction is originated by the customer. See Figure 2.

0064Scheme protocol:

00651. C — > B : Payment order ()_Cι

0066C orders a money transfer by the B.

00672. B — V : Payment confirmation ()_bt

0068B confirms the money transfer from C account to the V account.

0069Broker money transfer decisions.

0070Φ If broker receives from customer payment order ()c_ she transfers to the vendor account the amount of money equal to currency -unit * (. — j). Where j. is the index of previous member of customer authorization chain received by the broker from the customer.

0071• Broker confirms payment transfer of amount currency -unit * (. — j) by sending ()b_t to the vendor, where j is the index of previous member of broker authorization chain sent to the vendor by the broker.

0072Scheme properties:

0073• During the whole session the agents accept from the originator of the secure chain growing index series on submitted members of this secure chain only. Any member of the secure chain received from the originator of this secure chain with an index equal or less than already used is ignored and no action is required to undertake by the receiving agent. It is the responsibility of the agent submitting the secure chain member to obey this rule. • customer can decide to start paying at any moment.

0074• broker can check validity of c_. according to CQ and subsequent members of the customer authorization chain.

0075• vendor can check validity of bi according to 6₀ and subsequent members of the broker authorization chain.

0076• vendor expects payment confirmation to start sending data paid by the customer.

0077• The session is running while customer is paying.

0078Examples: any kind of endless data stream, stock exchange data, press agency news.

0079Scheme 2.

0080Customer is paying fix price on the vendor requirement. See Figure 3.

0081Scheme protocol:

00821. V — > C : Payment request (v_t)

0083V requires a payment by sending the next subsequent member of the payment chain υ-.

00842. C → B : Payment order ()_Cι

0085C orders a money transfer by the B.

00863. B — > V : Payment confirmation ()_bt

0087B confirms the money transfer from C account to the V account.

0088Broker money transfer decisions: the same as in scheme 1.

0089Scheme properties: the same as in scheme 1.

0090• Except that customer shall wait for vendor requirement to start paying.

0091• In addition customer can check the price versus payment requirement by the vendor according to parameters set in the data structure TokenBase.

0092Examples: video-on-demand, Internet service providing, phone call.

0093Scheme 3.

0094Customer is paying variable price on vendor requirement. See Figure 4.

0095Scheme protocol:

00961. V → C : Payment request (v_Ut , ni)

0097V requires C to pay the amount of currency .unit * (n_ — π_._ι )

00982. C -» B : Payment order (v_nι , ni)_c.

00993. B -4 V : Payment confirmation (υ_n, _>ⁿ_.)₆, Broker money transfer decisions.

0100• If broker receives from customer payment order (v_nι , n_t)_c , she transfers to the vendor account the amount of money equal to currency -unit * (π_ — ni-ι). Where n__ι is the index of previous member of vendor payment chain received by the broker from the customer. • vendor receives from broker payment confirmation (v_nι, n_t)_b - if broker transfers to the vendor account the amount of money equal to currency-unit * (n_t — n,_ι). Where n_τ- is the index of previous member of vendor payment chain sent to the vendor by the broker.

0101Scheme properties: the same as in scheme 1, 2.

0102• Except that vendor can require variable price by sending any member of the payment chain.

0103Examples: continuous watching of different TV programs with variable price.

0104Scheme 4.

0105Customer is paying variable price on vendor requirement. Customer can decide the sequence of payment orders. Except the customer also the broker receives payment requirements from the vendor. See Figure 5.

0106Scheme protocol:

01071. V — *• C : Payment request (v_nι , n_τ)

0108V — B : Information about payment request (v_Ui , n-)

01092. C — B : Payment order (v_nt, n_t)_c

01103. B — V : Payment confirmation (u_n. , π,)_,

0111Broker money transfer decisions.

0112• If broker receives from customer payment order (v_Ui , n_ϊ)_Cj , she transfers to the vendor account the amount of money equal to currencyjumt * {n- — n_t- ). Where ,_ι is the index of previous member of vendor payment chain received by the broker from the vendor.

0113• vendor receives from broker payment confirmation (v_n^ ^)^ , if broker transfers to the vendor account the amount of money equal to currency -unit * (n_τ — n_t_ι). Where n_t-_\ is the index of previous member of vendor payment chain sent to the broker by the vendor.

0114Scheme properties: the same as in scheme 1, 2, 3.

0115• Except that customer can decide the sequence of payment orders.

0116This scheme enables the customer to accept payment requests in different order as they were received from the vendor. This is possible because except the customer also the broker is given the sequence of payment requirements from vendor. In this way broker can decide the exact amount of money ordered to transfer by the customer.

0117Example: Web page content.

0118Scheme 5.

0119Customer is paying variable price on vendor requirement. Customer can decide the sequence of payment orders. Broker receives all information about the amount of money ordered to transfer from the customer. See Figure 6.

0120Scheme protocol: 1. V → C : Payment request ((υ_n, , «ι)_> ■„.,_ n_t-ι))

01212. C → B : Payment order ((υ_n. , n_.), (υ_n,_ι , «ι-ι))c_J

01223. B → V : Payment confirmation {(v_n,, n_τ), (υ_n._₁ , "_I-ι))6_, Broker money transfer decisions.

0123• If broker receives from customer payment order (w_n. , n_t), (w_nι_, , n__ι)_c , she transfers to the vendor account the amount of money equal to currency -unit * (n_x — r_j_ι). Broker uses these part of the payment chain only if it was not used before in the customer payment order.

0124• Vendor receives from broker payment confirmation (v_n, , n_t), {v_n,_. , »ϊ_ι-ι)_& , if broker transfers to the vendor account the amount of money equal to currency .unit * (n_ — n__j_.).

0125This scheme enables the customer to accept payment requests in different order as they were received from the vendor because in each payment order the broker is given both members of the vendor payment chain, which determine the amount of money customer orders to transfer. In this way broker can decide the exact amount of money ordered to transfer by the customer. The protocol can be simplified by vendor sending only the next member of the payment chain (υ_Λ. , n_).

0126Example: the same as 4.

0127Security analysis of the schemes 1,2,3

0128Specifically, for the family of payment schemes already described it is vital that members of the secure chains with lower or equal indexes then already used are considered disclosed and ignored in the protocol messages when encountered.

0129We consider the scheme secure if the following rules are always valid:

01301. broker is the trusted authority of the session.

01312. vendor receives payment confirmation from the broker only if her account was increased by the amount confirmed.

01323. customer account was decreased by the amount ordered only if she sent the payment order to the broker.

0133Generally for the security of the public-key cryptographic protocol is vital that the secret key of the broker is known to the broker only. Otherwise:

0134• customer or vendor can not prove that the broker is cheating.

0135• An attacker can modify the certificates of the broker clients. Change client public key, then sign the payment order. ( rule 2. not valid )

0136• An attacker can send payment confirmations to the vendor. ( rule 1. not valid )

0137Public keys of the customer and the vendor are transmitted through the certificates which are signed by the broker. If these public keys are published an attacker can observe the protocol traffics, but is not able to brake the rules mentioned above because of the unique relation between:

0138• Cv and {VQ , TokenBase} y_sk • Cc and {c₀}c_sk

0139• C_B and {bo}_Bsk

0140For schemes 1, 2, 3 no fraud is possible even when transmitted over insecure channel, but an attacker is still able to manipulate the transmitted data and cause session cancelation due to inconsistencies. This could be avoided be using secure channels.

0141Security analysis of the schemes 4 and 5

0142The interception of an attacker to these schemes could cause misunderstanding in the extend of amount and specification for what piece of information the customer paid. Because the customer can decide to pay for some kind of information later, she can submit members of the payment chain already disclosed. In this case broker is not able to prove the origin of the submitted members of the payment chain in the payment order and can not disclose manipulation of the payment order by an attacker. But the broker can limit the extend of the damage by not accepting the same range of indexes twice. Anyway the vendor can receive money from customer which the customer did not intend to send. But it is obvious that there is no direct profit in this fraud to the third party. Transmission of this protocol messages between C,B and BN over a secure channel solves this problem.

0143Secure payment matrix

0144We suppose that h and g are two commutative cryptographically secure hash functions hg = gh. One possibility how to construct such function g is to compute g = h^l where i is a very large number.

0145The secure payment matrix is a matrix of hash function values constructed as follows:

01461. The value V^N is chosen in random.

01472. The last column <img file="WO02086830A1_D0001.tif" /> • • • , VNN) is constructed by successive application of function g to V_NN

01483. The rows are constructed by successive application of function h to the elements of the last column e.g. the first row (VQO , U₀ , . . . , VQN) is constructed by successive application of function h to υojv, the second row generation starts from V_\M and so on.

0149The matrix has a feature that the receiver of the values in the first column can easily verify by applying function g that they belong to the first column of the particular secure payment matrix. This construction provides a means for cheap generation of the secure starting values of the payment chains.

0150Session replication

0151It is vital for a micropayment scheme to minimize the number of public key operations as far as they are very expensive compared to the microscopic payment value.

0152During the session the public key operations occur only in the initialization phase where the shared secret is transmitted. Therefore in the present invention we define the following session replication method.

0153During the request for an initialization phase the customer specifies an uniquely identified previously created session. If other agents agree the shared secret data from the old session are copied and used also for the new session. Further there are two possibilities for the new session. 1. The initialization phase is empty and the payment transactions use the same secure chains as the original session.

01542. The initialization phase is using a secure payment matrix defined above and during the initialization phase only the payment chain starting value (vio, i) is sent from the vendor to the customer and further to the broker. In this case the shared secret is provided by the value VQQ which is taken from original session.

0155References

0156[1] Ronald L. Rivest et al., "Payword and micromint: Two simple micropayment schemes" , Fourth Cambridge Workshop on Security Protocols, Springer Verlag Apr. 1996.

0157[2] Jarecki et al., "Efficient micropayment system" , US Patent No. 5,999,919, Dec. 7, 1999.

0158[3] Ronald L. Rivest, "The MD5 message-digest algorithm", Internet Request for Comments, April 1992. RFC 1321.

0159[4] National Institute of Standards and Technology (NIST), "FIPS Publication 180: Secure Hash Standard (SHS)" , May 11, 1993.

0160[5] Rivest et al., "Cryptographic Communication System and Method", US Patent No. 4,405,829, Dec. 7, 1999.