METHOD FOR SECURE PAYMENT WITH MICROPAYMENT CAPABILITIES

Abstract: A method for performing electronic payment transactions between at least three agents: a vendor, a customer and a broker each of which being able to connect to other two agents over a communication network. Values of cryptographically strong one-way hash function are used to secure the money transfer and authorize the agents involved in the transaction. The initialization of the payment session does not require any prearrangement over secure channel. Only one public-key cryptography operation is needed for each agent to distribute the shared secrets among the agents. Each subsequent transaction requires only calculation of few values of the hash function providing a method for efficient, cheap and fast micropayment system. The payment schemes based on the presented method are strongly debit oriented, avoiding troubles with fraud and double-spending. Method can be used over insecure channel. Each of the agents involved can encapsulate network of agents cooperating in the session.

Description: Patent application title: Method for secure payment with micropayment capabilities Authors: Dr.Tomas Hruz, DrNladimir Botka, Ing.Jan Stary Description Field of the Invention This 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. Background of the Invention Internet 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. Possible 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. 1. The payment granularity must range from 10 -6 to 10 2 USD and possibly should be dynamic as well. 2. The transaction cost of one payment must be cheaper then the payment itself. 3. The payment method must be secure. 4. 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. We 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. Our 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. Contrary 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. We 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. At 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. In 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 The further defined steps of the method claimed in the present patent are schematically shown in the following drawings: Figure 1 is a schematic diagram of the payment transaction initialization part of the proposed method. Figure 2 is a schematic diagram of the payment transaction method with the most simple payment information included. Figure 3 is a schematic diagram of the payment transaction method with a constant cost for each transaction. Figure 4 is a schematic diagram of the payment transaction method with variable cost for each transaction. Figure 5 is a schematic diagram of the payment transaction method with variable cost for each transaction and "not to pay" possibility for customer. Figure 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. Description of the Invention In the following we shall denote by small letters v, c, b cryptographically secure sequence of integers generated in the following way. To 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. If 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 3 to produce the same output h(v l ) = h(v 3 ). This sequence of integers we call a secure chain. We 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 s j-, 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 -. With 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 3 is an element of another secure chain c, starting from c 0 . 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. We 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. TokenBase With 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 TokenBase = { currency_type , currency , .unit { mantisa, exponent }, data_unit { type, time, kByte } > where: TokenBase — >• currency -type is the currency of the token. TokenBase — > currency .unit — mantisa is the mantissa of the financial value of the token. TokenBase — > currency .unit — exponent is the exponent of the financial value of the token. TokenBase — data-unit — type is the type of the payment session. TokenBase -> data unit — time in seconds is the price parameter of the payment session. TokenBase — > datajunit —> kByte in kBytes is the price parameter of the payment session. In 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. If 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. If 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 : • data -unit {type = I, time — 1, kByte = 0} means that the customer is required by the vendor to pay 1 cent per 1 second. • 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. • data.unit{type = 2, time = any, kByte = any} means that the customer is required to pay 1 cent on the vendor request. • 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 υ 3 of the payment chain originated by the vendor. Session We 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. Session initialization scheme Scheme protocol: 1. C — > ■ V : request The initialization of the "session" is started on the C request to V in any detectable form. 2. V → C : C υ , {vo, TokenBase}v sk V 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 0 , C v , {v 0 , TokenBase}v 3k }c 3k C 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 0 and all information she received from V in the previous step. The values received from V and c 0 are signed by the C. The certificate C c does not have to be signed. 4. B → V : {vo, b 0 } Bsk B 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 0 are signed by the B. The 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 0 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. The 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. In 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. Scheme 1. Customer is paying fix price per time or data amount. The payment transaction is originated by the customer. See Figure 2. Scheme protocol: 1. C — > B : Payment order () Cι C orders a money transfer by the B. 2. B — V : Payment confirmation () bt B confirms the money transfer from C account to the V account. Broker money transfer decisions. Φ 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. • 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. Scheme properties: • 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. • broker can check validity of c . according to CQ and subsequent members of the customer authorization chain. • vendor can check validity of bi according to 6 0 and subsequent members of the broker authorization chain. • vendor expects payment confirmation to start sending data paid by the customer. • The session is running while customer is paying. Examples: any kind of endless data stream, stock exchange data, press agency news. Scheme 2. Customer is paying fix price on the vendor requirement. See Figure 3. Scheme protocol: 1. V — > C : Payment request (v t ) V requires a payment by sending the next subsequent member of the payment chain υ-. 2. C → B : Payment order () Cι C orders a money transfer by the B. 3. B — > V : Payment confirmation () bt B confirms the money transfer from C account to the V account. Broker money transfer decisions: the same as in scheme 1. Scheme properties: the same as in scheme 1. • Except that customer shall wait for vendor requirement to start paying. • In addition customer can check the price versus payment requirement by the vendor according to parameters set in the data structure TokenBase. Examples: video-on-demand, Internet service providing, phone call. Scheme 3. Customer is paying variable price on vendor requirement. See Figure 4. Scheme protocol: 1. V → C : Payment request (v Ut , ni) V requires C to pay the amount of currency .unit * (n_ — π . _ι ) 2. C -» B : Payment order (v nι , ni) c . 3. B -4 V : Payment confirmation (υ n , > n . ) 6 , Broker money transfer decisions. • 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. Scheme properties: the same as in scheme 1, 2. • Except that vendor can require variable price by sending any member of the payment chain. Examples: continuous watching of different TV programs with variable price. Scheme 4. Customer 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. Scheme protocol: 1. V — *• C : Payment request (v nι , n τ ) V — B : Information about payment request (v Ui , n-) 2. C — B : Payment order (v nt , n t ) c 3. B — V : Payment confirmation (u n . , π,)_, Broker money transfer decisions. • 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. • 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. Scheme properties: the same as in scheme 1, 2, 3. • Except that customer can decide the sequence of payment orders. This 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. Example: Web page content. Scheme 5. Customer 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. Scheme protocol: 1. V → C : Payment request ((υ n , , «ι) > ■„.,_ n t -ι)) 2. C → B : Payment order ((υ n . , n . ), (υ n ,_ι , «ι-ι))c J 3. B → V : Payment confirmation {(v n ,, n τ ), (υ n ._ 1 , " I -ι))6_, Broker money transfer decisions. • 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. • 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 . ). This 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_). Example: the same as 4. Security analysis of the schemes 1,2,3 Specifically, 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. We consider the scheme secure if the following rules are always valid: 1. broker is the trusted authority of the session. 2. vendor receives payment confirmation from the broker only if her account was increased by the amount confirmed. 3. customer account was decreased by the amount ordered only if she sent the payment order to the broker. Generally 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: • customer or vendor can not prove that the broker is cheating. • An attacker can modify the certificates of the broker clients. Change client public key, then sign the payment order. ( rule 2. not valid ) • An attacker can send payment confirmations to the vendor. ( rule 1. not valid ) Public 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: • Cv and {VQ , TokenBase} y sk • Cc and {c 0 }c sk • C B and {bo} Bsk For 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. Security analysis of the schemes 4 and 5 The 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. Secure payment matrix We 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. The secure payment matrix is a matrix of hash function values constructed as follows: 1. The value V^N is chosen in random. 2. The last column • • • , VNN) is constructed by successive application of function g to V NN 3. The rows are constructed by successive application of function h to the elements of the last column e.g. the first row (VQO , U 0 , . . . , VQN) is constructed by successive application of function h to υojv, the second row generation starts from V \ M and so on. The 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. Session replication It 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. During 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. During 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. 2. 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. References [1] Ronald L. Rivest et al., "Payword and micromint: Two simple micropayment schemes" , Fourth Cambridge Workshop on Security Protocols, Springer Verlag Apr. 1996. [2] Jarecki et al., "Efficient micropayment system" , US Patent No. 5,999,919, Dec. 7, 1999. [3] Ronald L. Rivest, "The MD5 message-digest algorithm", Internet Request for Comments, April 1992. RFC 1321. [4] National Institute of Standards and Technology (NIST), "FIPS Publication 180: Secure Hash Standard (SHS)" , May 11, 1993. [5] Rivest et al., "Cryptographic Communication System and Method", US Patent No. 4,405,829, Dec. 7, 1999.

Claims: Patent application title: Method for secure payment with micropayment capabilities Authors: Dr.Tomas Hruz, Dr. Vladimir Botka, Ing.Jan Stary Claims 1. A method for secure payment operation involving three agents, a customer, a broker and a vendor wherein the said method comprises an initialization phase consisting in a cyclic propagation of a share secret and a continuation phase consisting in a cyclic propagation of payment transaction tokens wherein the said payment operation is uniquely identified as session and all shared data of a said session are stored as the session attributes. 2. The method of claim 1 wherein the initialization phase comprises step 1. during which the customer sends to the vendor a request, step 2. during which the vendor sends to the customer the data C υ , {υo, TokenBase}v sk , step 3. during which the customer sends to the broker the data C c , {c 0 , C υ , {vo, TokenBase}v. k }c sk an d step 4. during which the broker sends to the vendor the data {vo, bo}β- k - 3. The method of claims 1 and 2 wherein the continuation phase comprises step 1. during which the customer sends to the broker the payment order () Cj and step 2. during which the broker sends to the vendor payment confirmation () & . wherein the said steps are repeated until the session is not finished by the decision of any of the agents. 4. The method of claims 1 and 2 wherein the continuation phase comprises step 1. during which the vendor sends to the customer the payment request (υ_), step 2. during which the customer sends to the broker the payment order () Cι and step 3. during which the broker sends to the vendor the payment confirmation ();, t wherein the said steps are repeated until the session is not finished by the decision of any of the agents. 5. The method of claims 1 and 2 wherein the continuation phase comprises step 1. during which the vendor sends to the customer the payment request (v nt , n t ), step 2. during which the customer sends to the broker the payment order (v rlt , n l ) Cj and step 3. during which the broker sends to the vendor the payment confirmation v n ^ n^i, wherein the said steps are repeated until the session is not finished by the decision of any of the agents. 6. The method of claims 1 and 2 wherein the continuation phase comprises step 1. during which the vendor sends to the customer the payment request (υ„ t , n-) , step 2. during which the vendor sends to the broker an information about the payment request (v nχ , n t ), step 3. during which the customer sends to the broker the payment order {v rit , n l ) c and step 4. during which the broker sends to the vendor the payment confirmation v n ^ n,,)), wherein the said steps are repeated until the session is not finished by the decision of any of the agents. 7. The method of claims 1 and 2 wherein the continuation phase comprises step 1. during which the vendor sends to the customer the payment request {{v n , , τι t ), (υ riι _ 1 , n l -ι)), step 2. during which the customer sends to the broker the payment order ({v Ui , n t ), {v nι _ ϊ , n 1 - \ )) c and step 3. during which the broker sends to the vendor the payment confirmation {{v n , ) n-), {v nι _. , rij-i));,. wherein the said steps are repeated until the session is not finished by the decision of any of the agents. 8. The method of any one claims 1 to 7 wherein any one of the customer, broker and vendor are complex networks itself using internally the methods of any one claims 1 to 7. 9. The method of claims 1, 3, 4, 5, 6, 7, 8 wherein the initialization phase is empty or comprises usage of secure payment matrix and all other necessary data are copied from uniquely specified already created session. 10. The method of claim 9 wherein the secure payment matrix comprises a matrix constructed from two commutative cryptographically secure hash functions /, g in a method comprising step 1. where the value υj w is chosen in random, step 2. where the last column (VQJ , V \ N , . . . , VJ N) is constructed by successive application of function g to υjv_v and step 3. where the rows are constructed by successive application of function h to the elements of the last column.

Inventors: BOTKA VLADIMIR, HRUZ TOMAS, STARY JAN, BOTKA, VLADIMIR, HRUZ, TOMAS, STARY, JAN
Applicants: BOTKA VLADIMIR, HRUZ TOMAS, STARY JAN, BOTKA, VLADIMIR, HRUZ, TOMAS, STARY, JAN
Application year: 2001
Main classification: G07F19
IPC codes: G06Q20