+

WO2009100112A2 - Système agrégé de chaîne de hachage de micropaiement - Google Patents

Système agrégé de chaîne de hachage de micropaiement Download PDF

Info

Publication number
WO2009100112A2
WO2009100112A2 PCT/US2009/033047 US2009033047W WO2009100112A2 WO 2009100112 A2 WO2009100112 A2 WO 2009100112A2 US 2009033047 W US2009033047 W US 2009033047W WO 2009100112 A2 WO2009100112 A2 WO 2009100112A2
Authority
WO
WIPO (PCT)
Prior art keywords
vendor
payer
commitment
broker
payment
Prior art date
Application number
PCT/US2009/033047
Other languages
English (en)
Other versions
WO2009100112A3 (fr
Inventor
Mahesh V. Tripunitara
Thomas S. Messerges
Original Assignee
Motorola, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Motorola, Inc. filed Critical Motorola, Inc.
Publication of WO2009100112A2 publication Critical patent/WO2009100112A2/fr
Publication of WO2009100112A3 publication Critical patent/WO2009100112A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the present invention relates generally to computer communications, and, more particularly, to encryption-based methods for transferring micropayments.
  • Micropayment systems have been proposed to handle these small, incremental payments in a manner cost-effective both to the end customers and to the vendors.
  • Some of these systems use a cryptographic construct called a "hash chain.”
  • a hash chain is generated by repeated applications of a cryptographic hash function. Each entry in a hash chain is then used to verify a micropayment.
  • a broker verifies the micropayments, reimburses the vendor, and charges the end customer. Because cryptographic hash chains allow a service provider or vendor to aggregate individual micropayments, he saves on transaction costs with the broker.
  • a hash-chain-based system also provides for non-repudiation and prevents fraudulent accounting by service providers and vendors.
  • micropayments are represented by individual hash-chain members.
  • the hash chains are then aggregated to provide a more efficient data exchange between a vendor and a broker.
  • an end user (here called the "payer") cryptographically signs “commitments” and transmits then to a vendor (i.e., a network-service provider).
  • a vendor i.e., a network-service provider.
  • Each commitment includes an anchor of a hash chain and an "accumulated count” field which tracks the total number of micropayments made thus far in the payment transaction between the payer and the vendor.
  • the payer can also transmit payment tokens to the vendor.
  • Each payment token includes an element of the hash chain, the hash chain being secured by the anchor included in the commitment.
  • the vendor When the vendor seeks reimbursement from a broker, the vendor tells the broker the total number of micropayments in the payment transaction. (The number may be based, for example, on the accumulated count in the last commitment of the payment transaction plus any micropayments made in payment tokens after the last commitment). The vendor need not send every intervening commitment to the broker. This saves on transmission costs between the vendor and the broker and on storage costs for both of them.
  • a verification system is established between the broker and the payer.
  • the commitments transmitted by the payer to the vendor include information tied to this verification system.
  • the verification information can include a timestamp or a counter.
  • the vendor checks the authenticity of the payer's commitments and micropayments. In turn, the vendor sends verification information to the broker. The broker checks this information against the verification system established with the payer. If the information is verified to be correct, then the broker reimburses the vendor for the services provided and charges the payer.
  • the verification information ensures that the payer and vendor cannot cheat each other by, for example, repudiating legitimate payments or by submitting the same information for multiple reimbursements.
  • Figure 1 is a sketch showing the three parties in a payment transaction
  • Figure 2 is a sketch of a prior-art technique of using hash chains to make micropayments
  • Figure 3 is a sketch of a payment transaction according to aspects of the present invention.
  • Figure 4 is a flowchart of a payer interacting with a vendor according to an exemplary embodiment of the present invention
  • Figure 5 is a flowchart of a vendor interacting with a payer and with a broker
  • Figure 6 is a flowchart of a broker interacting with a vendor
  • Figure 7 is a graph comparing the amount of processing time required of a broker under a prior-art system and under a system according to the present invention
  • Figure 8 is a graph comparing the amount processing time required of a payer under a prior-art system and under a system according to the present invention.
  • Figure 9 is a graph comparing the amount of storage required of a vendor under a prior-art system and under a system according to the present invention.
  • Figure 1 introduces the players and the interactions among them that together make up a payment/reimbursement transaction.
  • a payer 100 wishes to buy services from a vendor or service provider 102.
  • the types of services are not relevant to the present invention but could include telephony services, access to web-based content, and the like.
  • the payer 100 sends digital payment indications (discussed in great detail below) to the vendor 102 who, in turn, provides the requested services.
  • the vendor 102 seeks reimbursement from the broker 104.
  • the broker 104 checks verification information provided during the payment transaction and, if all is well, reimburses the vendor 102 and bills the payer 100.
  • the payer 100 first establishes an account with the broker 104 and sets up a system for verifying payments.
  • the payer 100 uses some mechanism (beyond the scope of Figure 1) to pay the broker 104 when the broker 104 bills him for the services the payer 100 has purchased from the vendor 102.
  • eo is called the anchor of the hash chain
  • e c+1 is a (virtually) random number
  • ei h(ei+l) for the hash function
  • Hash chains were first proposed in the context of one-time passwords and have since been proposed for micropayments. In the context of micropayments, each entry in the hash chain is used as a payment worth some pre-determined amount. Specifically, prior-art micropayment techniques often include the following steps. (These steps, modified as appropriate, are also used in the discussion below to describe embodiments of the present invention.)
  • Step 1 The broker 104 issues a certificate Cu to the payer 100. This is an offline step that happens infrequently relative to the number of payments that the payer 100 makes. At a minimum, Cu includes
  • B identifies the broker 104
  • U identifies the payer 100 (e.g., by an account number)
  • Pubu is the public portion of a public-private key pair associated with the account of the payer 100
  • E is the expiration date of the certificate.
  • Cu represents an assurance to a vendor 102 that the broker 104 will reimburse the vendor 102 for payments made by the payer 100.
  • Step 2 The payer 100 initiates a payment transaction with the vendor 102. To do so, the payer 100 generates a hash chain eo, . . ., e c+1 . (In other cases, the hash chain is generated by the broker 104.) The payer 100 commits to e0 by signing a suitable commitment message M with the private portion of his public-private key pair, Privu- The payer 100 then sends the message M to the vendor 102, perhaps along with Cu- This message M gives context to the payment transaction.
  • V identifies the vendor 102
  • U identifies the payer 100 (e.g., by an account number as described above)
  • eo is the anchor of the hash chain that the payer 100 intends to use for payments
  • D is the current date
  • A is additional information such as a description of the services or goods that the payer 100 wishes to buy from the vendor 102 and the value associated with each entry in the hash chain.
  • the payer 100 makes the ith payment by sending a payment token including Q[. to the vendor 102.
  • Step 3 The vendor 102 accepts a payment from the payer 100 after verifying it.
  • the vendor 102 Upon receipt of the commitment message M, the vendor 102 verifies the signature on M and may check with the broker 104 to see whether Cu is still valid.
  • the vendor 102 then provides goods or services to the payer 100.
  • the payer 100 does not have to explicitly indicate to the vendor 102 when he is done using the services.
  • Step 4 The vendor 102 requests reimbursement from the broker 104 by sending to the broker 104 a message (M, ei, i) for each M to which the payer 100 has committed.
  • M ei, i
  • i is the index of the last payment made in the corresponding payment transaction.
  • Step 5 The broker 104 verifies what the vendor 102 sends him. Specifically, the broker 104 checks that the signatures, the fields in the commitments, and the hash chains are valid, and that no previously used hash chain has been reused. The broker 104 then reimburses the vendor 102 and bills the payer 100.
  • FIG. 2 illustrates Steps 2 and 4 of the above prior-art system.
  • the payments 200, 202, and 204 each include a commitment message.
  • the payments 200, 202, and 204 also include entries from three hash chains of lengths i, j, and k, respectively.
  • the vendor 102 requests a reimbursement 206, 208, and 210 for each of these hash chains. To do so, the vendor 102 only needs to send to the broker 104 the final entry in each hash chain along with the corresponding commitment.
  • This aggregation decreases the amount of data that the vendor 102 needs to send to the broker 104 when requesting reimbursement.
  • the broker 104 has reduced computation costs as he only needs to verify the signature on every commitment and not on every payment. Hash chains also reduce the computation needed in the device of the payer 100 as not every payment needs to be signed.
  • the prior-art system of Figure 2 also has some disadvantages.
  • the payer 100 must guess the length of the hash chain he intends to use to make payments.
  • time-space tradeoffs are important issues because many payers 100 use a portable device such as a mobile phone or PDA with limited storage and processing power.
  • hash-chain length also affects the vendor 102 and the broker 104.
  • the vendor 102 would have had to use only a third as much processing time and storage space.
  • the vendor 102 transfers all of these commitments to the broker 104.
  • the payer 100 makes 10,000 micropayments each worth a tenth of a penny and chooses a hash-chain length of 10
  • the vendor 102 will store 1,000 commitments for a $10 payment transaction.
  • the vendor 102 transfer all of these commitments to the broker 104 when requesting reimbursement.
  • the broker 104 verifies every hash- chain member and therefore, in this example, the broker 104 performs 10,000 hash verifications. Even though hash functions are generally much easier to verify than public-key signatures, the broker 104 has to perform considerable computations for each payment transaction. This is in addition to the 1,000 public-key signature verifications that correspond to the 1,000 hash chain commitments. Finally, to prevent double spending, the vendor 102 and the broker 104 each stores (the hash of) each reimbursed commitment.
  • Step 1 of an embodiment of the present invention is similar to Step 1 as described above:
  • the payer 100 receives a certificate from a trusted authority which could be, but need not be, the broker 104. (See Step 400 of Figure 4a.)
  • Step 2 in the present embodiment can differ from the above described Step 2 in numerous ways.
  • a commitment includes three new fields. One field is called the "accumulated count,” a second field is the “verifier,” and a third field is a "transaction identifier.” (Various embodiments exclude one or more of these fields, as discussed in detail below. The present discussion is meant to be broadly illustrative rather than limiting.)
  • Step 2 can be repeated within one payment transaction, that is, a single payment transaction can include multiple commitments.
  • each hash chain 200, 202, and 204 used by the payer 100 to make micropayments to the vendor 102 leads to a separate reimbursement transaction 206, 208, and 210 between the vendor 102 and the broker 104.
  • one reimbursement transaction 306 in Figure 3 corresponds to multiple hash chains 300, 302, and 304.
  • the accumulated count field allows this aggregation.
  • the accumulated count field is initialized before any commitments are sent (Step 402 of Figure 4a). Whenever a new hash chain is needed in the payment transaction (Step 404), a new commitment with the new hash- chain anchor and the accumulated count is sent to the vendor 102 (Step 406).
  • the accumulated count records the number of micropayments made thus far in the payment transaction.
  • the accumulated count can be set to 0 in the first commitment that sets up the first hash chain 300.
  • the accumulated count is set to i, the number of micropayments made under the first hash chain (Step 410 of Figure 4b).
  • the third commitment is sent to begin the third hash chain 304, the accumulated count is set to i+j. The effect of the accumulated count on the reimbursement transaction 306 is discussed below in reference to Steps 4 and 5.
  • the payer 100 can send payment tokens to the vendor 102, each token including a member of the current hash chain to indicate payment (Step 408 of Figure 4a).
  • the first commitment in a payment transaction either does not include an accumulated count (in which case it is assumed to be zero), or it includes a non-zero (possibly random) number. These cases are described below in the discussion of Steps 4 and 5.
  • the accumulated count allows the commitments to replace some or all of the payment tokens. Because the accumulated count tracks the number of micropayments made in the payment transaction between the payer 100 and the vendor 102, the payer 100 can indicate payments simply by sending the commitments rather than by sending payment tokens. The accounting for payments is discussed below in reference to Steps 4 and 5.
  • the verifier field is used differently in different embodiments of the present invention.
  • the verifier is a timestamp that records the relative or actual time when a commitment is made. (In this case, the date field D discussed above may be redundant.)
  • the timestamp is of sufficient granularity that no two commitments in the same payment transaction between the payer 100 and the vendor 102 can have the same value.
  • the timestamp in Mi is smaller than the timestamp in M 2 .
  • Some embodiments use the current time (in GMT, say) to a sufficient granularity for the verifier timestamp.
  • the verifier field is an ordered counter. The counter is checked to make sure that it always progresses monotonically in a pre-agreed manner (e.g., always increases or always decreases) from one commitment to the next within a given payment transaction.
  • Some embodiments include a transaction identifier field in each commitment. This is useful if the vendor 102 intends to support concurrent payment transactions with the payer 100.
  • the anchor of the hash chain can serve as a transaction identifier.
  • the anchor of the first hash chain in a payment transaction can work as well, as long as the payer 100 does not attempt to reuse that hash chain.
  • Step 3 the vendor 102 can receive multiple commitments in one payment transaction (Step 500 of Figure 5a).
  • the vendor 102 can choose to verify the information in the commitment including the signature of the payer 100 (Step 502), the verifier (Step 504), and the accumulated count (Step 506). As discussed above, the payer 100 can send payment tokens to the vendor 102 (Step 508), but in some embodiments the accumulated count in the commitments replaces some or all of these payment tokens. If the vendor 102 receives a payment token (Step 508), then the vendor 102 can verify that the included hash-chain member is in fact a valid member of the hash chain set up by the most recently received commitment (Step 510 of Figure 5b).
  • Step 4 the vendor 102 seeks reimbursement from the broker 104 for the payment transaction.
  • the vendor 102 has to send one reimbursement request 206, 208, 210 for each hash chain 200, 203, 204 used in the payment transaction.
  • the vendor 102 aggregates these requests into one reimbursement request 306.
  • the vendor 102 provides to the broker 104 information that allows the broker 104 to determine the amount of the reimbursement and information that allows the broker 104 to confirm the validity of the reimbursement.
  • the reimbursement request message 306 includes (M 1 , M n , e ⁇ i) (Step 514 of Figure 5b).
  • M 1 is the first commitment in the payment transaction
  • M n is the final commitment in the payment transaction
  • ei is the last entry in the hash chain corresponding to the anchor in M n
  • i is the index of Q[ in that hash chain.
  • the number of individual micropayments incurred by the payer 100 in this payment transaction is C n +i, where C n is the value of the accumulated count field in the final commitment M n .
  • C n represents the total number of micropayments made in the payment transaction before the final commitment M n was sent
  • i represents the number of micropayments in the payment transaction made after that final commitment M n .
  • the number of micropayments is equal to the difference between the accumulated count C n in the final commitment M n and the accumulated count Ci in the first commitment Mi (plus the index i representing payment tokens sent after the final commitment M n , if any), (d)
  • the index i is not actually sent but is deduced by the broker 104.
  • the index i is equal to the number of times it takes to hash ei to reach the eo contained in the commitment M n .
  • Step 5 the broker 104 receives the reimbursement request 306 (Step 600 of Figure 6) and proceeds to verify it.
  • the broker 104 first verifies that the first Mi and final commitments M n were indeed signed by the payer 100.
  • the broker 104 verifies the verifiers in the first Mi and final commitments M n (Step 602).
  • the broker establishes a "verifier threshold" for reimbursement requests 306. For every reimbursement request 306, the verifier in the first commitment Mi should fall after this established verification threshold. Any reimbursement request 306 that violates this rule is rejected by the broker 104.
  • the broker 104 sets one verification threshold per payer 100, in other embodiments there is one per payer 100/vendor 102 pair, or one per payer 100/vendor 102/type of service triplet. (The choice is one of broker policy. The finer the granularity that the broker 104 supports, the more flexibility it provides to the vendor 102; however, this means that the broker 104 allocates more storage.)
  • the broker 104 only has to store the verification threshold rather than, as in the prior-art technique, (the hashes of) all previous commitments.
  • the vendor 102 is aware of this verification threshold and uses it to verify the verifiers received in commitments (Step 504 of Figure 5 a).
  • the broker 104 may then establish a new verification threshold for the next round of reimbursement requests 306.
  • the new verification threshold is the last verifier (e.g., the latest timestamp) across all of the final commitments in the current set of reimbursement requests 306 from the vendor 102.
  • the broker 104 calculates the number of micropayments represented by the request 306. (Variations in this process are described above in reference to Step 4.) The broker 104 then translates this number of micropayments into a reimbursement amount (possibly minus a transaction fee) (Step 604 of Figure 6), reimburses the vendor 102 (Step 516 of Figure 5b and Step 606 of Figure 6), and charges the payer 100.
  • the present inventions provides advantages in performance (storage space and processing time) over prior-art techniques. To illustrate these advantages, the following discussion compares an embodiment of the prior-art technique with an embodiment of the present invention. As different embodiments exhibit different performance characteristics, this discussion is illustrative only and is not meant to limit the invention in any way.
  • I I is the ceiling function.
  • the p component represents the number of hashes to be verified.
  • x t v represents the number of commitments made by the payer 100 to make p payments and the signatures on those commitments that need to be verified.
  • x 1 represents the need to compute the hash of each commitment to compare with the hashes of prior commitments for payment transactions that have already been reimbursed.
  • the time to process p payments from the payer 100 at the vendor 102 is:
  • the vendor 102 verifies p hashes and I p/h
  • T o i d an d T vnew suggest, the difference between the processing times at the vendor 102 is attributable to the prior art's need to check against previous commitments.
  • the advantage of embodiments of the present invention grows linearly with the ratio p/h.
  • the time to process these p payments at the broker 104 is:
  • Figure 7 indicates that given a hash chain length h, and the possibility that p may exceed h, it is beneficial for the vendor 102 and for the broker 104 to use an embodiment of the present invention rather than the prior-art technique. Also, in the embodiment of the present invention, given two hash-chain lengths Jl 1 and h 2 such that Jl 1 ⁇ h 2 , it is beneficial for the broker 104 that payments are made using hash chains of length hi rather than h 2 if p > h 2 .
  • the payer 100 makes a tradeoff in choosing the length h of the hash chain. Because the payer 100 is not always able to predict exactly how many payments he will make, he runs the risk of generating a long hash chain and wasting either time or space or both. Embodiments of the present invention provide flexibility because the payer 100 can still choose relatively short hash chains and not waste processing time or space. To quantify the risk from the prior-art technique, consider two hash chain lengths, h s and hi, with hi » h s . Consider the case where the payer 100 is willing to trade off time for space.
  • the total processing time at the payer 100 under the prior-art technique in this case is:
  • processing time for the payer 100 when using an embodiment of the present invention is:
  • Figure 8 demonstrates that it is not always in the best interest of the payer 100 to use longer hash chains.
  • embodiments of the present invention provide processing-time benefits to the vendor 102 and to the broker 104.
  • the prior-art and present techniques are identical in terms of processing time for the payer 100.
  • embodiments of the present invention are still advantageous for the payer 100 because they perform well even with smaller hash chains. Smaller hash chains are beneficial to the payer 100 because he does not risk wasting processing time or storage space.
  • S h be the space needed to store an entry from a hash chain
  • S c be the space needed to store a commitment.
  • S h is 20 bytes for the hash plus 4 bytes for the index in the hash chain.
  • the size of S c includes the signature, which is about 60 bytes for a 163 -bit curve 3 ECC cryptosystem; however, S c includes whatever else is in the commitment, such as the (hash of the) service agreement between the payer 100 and the vendor 102. It is expected that S c is about five times the size of S h .
  • the space required at the payer 100 for payments is the same in the prior- art and present techniques.
  • the payer 100 needs to store the unspent entries from the hash chain.
  • the waste of space at the payer 100 has a linear relationship to the number of payments he makes.
  • the payer 100 can store receipts for payments he has already made.
  • a receipt includes
  • the space required by an embodiment of the present invention is very different from the requirements under the prior art.
  • the broker 104 stores only one timestamp once he has reimbursed the vendor 102 for any reimbursement requests.
  • the corresponding space requirement is S c x I p/h
  • r reflects the fact that the vendor 102 stores (the hash of) previous commitments so that he can check against them to detect any attempts by the payer 100 to double spend.
  • these r hashes are also stored at the broker 104 to ensure that the vendor 102 does not attempt to get reimbursed more than once for the same payment transaction.
  • the vendor 102 reaps tremendous space and data-transfer benefits.
  • the broker 104 processes less data and stores dramatically less data.
  • the payer 100 uses less storage space for receipts for payments already made.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention concerne un système et un procédé destinés à agréger des chaînes de hachage de micropaiement (300, 302, 304). Un utilisateur final (le "payeur") (100) signe de manière cryptographique des "engagements" et les transmet (406) à un vendeur (102). Les engagements comprennent un champ "compte cumulatif" qui suit le nombre total de micropaiements effectués jusqu’alors dans la transaction de paiement entre le payeur (100) et le vendeur (102). Le payeur (100) peut aussi transmettre (408) des jetons de paiement au vendeur (102). Ces jetons de paiement comprennent des micropaiements vérifiés par une chaîne de hachage (300, 302, 304). Lorsque le vendeur (102) demande (514) un remboursement à un courtier (104), le vendeur (102) informe le courtier (104) du nombre total de micropaiements dans la transaction de paiement et envoie des informations de vérification au courtier (104). Le courtier (104) vérifie (602) cette information auprès d’un système de vérification établi avec le payeur (100). Si la vérification de l’information indique que cette dernière est correcte, le courtier (104) rembourse (606) le vendeur (102) pour les services rendus et facture (606) le payeur (100). L’information de vérification assure que le payeur (100) et le vendeur (102) ne peuvent se frauder mutuellement.
PCT/US2009/033047 2008-02-06 2009-02-04 Système agrégé de chaîne de hachage de micropaiement WO2009100112A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12/026,694 2008-02-06
US12/026,694 US20090198619A1 (en) 2008-02-06 2008-02-06 Aggregated hash-chain micropayment system

Publications (2)

Publication Number Publication Date
WO2009100112A2 true WO2009100112A2 (fr) 2009-08-13
WO2009100112A3 WO2009100112A3 (fr) 2009-11-05

Family

ID=40932605

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2009/033047 WO2009100112A2 (fr) 2008-02-06 2009-02-04 Système agrégé de chaîne de hachage de micropaiement

Country Status (2)

Country Link
US (1) US20090198619A1 (fr)
WO (1) WO2009100112A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9871786B2 (en) 2015-07-23 2018-01-16 Google Llc Authenticating communications

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8260721B2 (en) 2007-09-24 2012-09-04 Cheng Holdings, Llc Network resource access control methods and systems using transactional artifacts
US8607057B2 (en) * 2009-05-15 2013-12-10 Microsoft Corporation Secure outsourced aggregation with one-way chains
US10374799B2 (en) * 2011-04-13 2019-08-06 Nokia Technologies Oy Method and apparatus for identity based ticketing
US9026784B2 (en) * 2012-01-26 2015-05-05 Mcafee, Inc. System and method for innovative management of transport layer security session tickets in a network environment
US20130212024A1 (en) * 2012-02-10 2013-08-15 Protegrity Corporation Tokenization in distributed payment environments
EP2930880A4 (fr) * 2012-12-05 2016-08-03 Sony Corp Processeur d'informations, processeur de vérification, procédé de traitement d'informations, procédé de traitement de vérification, et programme
WO2015024129A1 (fr) * 2013-08-21 2015-02-26 Trent Lorne Mcconaghy Procédé pour établir, confirmer et transférer de manière sécurisée la propriété d'œuvres d'art
AU2016235539B2 (en) * 2015-03-20 2019-01-24 Rivetz Corp. Automated attestation of device integrity using the block chain
US20160335609A1 (en) * 2015-05-15 2016-11-17 Gareth Jenkins Representation of digital asset structure, ownership and evolution by virtue of a hierarchical, compounding tagging mechanism on a transaction-based network
KR102468390B1 (ko) * 2017-05-31 2022-11-18 삼성에스디에스 주식회사 토큰 관리 방법 및 이를 수행하기 위한 서버
CN108960826B (zh) * 2018-06-29 2021-02-09 杭州复杂美科技有限公司 一种交易组、交易组构造方法、存储介质、设备和系统
US11777712B2 (en) * 2019-03-22 2023-10-03 International Business Machines Corporation Information management in a database
US11438152B2 (en) 2020-01-31 2022-09-06 Visa International Service Association Distributed symmetric encryption
EP4144042B1 (fr) * 2020-04-28 2025-01-29 Visa International Service Association Chiffrement symétrique distribué résistant aux attaques adaptatif
US11431487B2 (en) 2020-04-28 2022-08-30 Visa International Service Association Adaptive attack resistant distributed symmetric encryption
CN113204797A (zh) * 2021-05-10 2021-08-03 华东桐柏抽水蓄能发电有限责任公司 一种基于区块链技术的物联网大坝监测系统架构方法
US11564266B1 (en) 2022-07-11 2023-01-24 Starkeys Llc Permission-based controlling network architectures and systems, having cellular network components and elements modified to host permission controlling schemas designed to facilitates electronic peer-to-peer communication sessions methods for use thereof
US11533619B1 (en) 2022-05-22 2022-12-20 Starkeys Llc Access controlling network architectures utilizing novel cellular signaled access control and machine-learning techniques to identify, rank modify and/or control automated programmable entities (such as robots/bots) and their visual schemas, and methods for use thereof
US11516666B1 (en) 2022-05-22 2022-11-29 Starkeys Llc Access controlling network architectures utilizing cellular signaled access control to restricted services with expected keys in accordance with novel communications protocols, and methods for use thereof
US11432154B1 (en) 2021-12-31 2022-08-30 Ari Kahn Cellular systems having elements modified for access control based on expectation data records in accordance with novel cellular communications protocols and network architectures utilizing cellular network hosted access controlling schemas, and methods for use thereof
US11388601B1 (en) 2021-12-31 2022-07-12 Ari Kahn Cellular systems having elements modified to transform and/or operate cellular communication signals in accordance with novel cellular communications protocols and network architectures utilizing cellular network hosted access controlling schemas, and methods for use thereof
US11477654B1 (en) 2022-05-31 2022-10-18 Starlogik Ip Llc Access controlling network architectures and systems, having cellular network components and elements modified to host access controlling schemas designed to transform and/or facilitate cellular communication signals in accordance with novel cellular communications protocols with multi-part multi-functional address signaling, and methods for use thereof

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20010068434A (ko) * 2000-01-05 2001-07-23 이임영 소액 전자상거래 방법
WO2004068293A2 (fr) * 2003-01-25 2004-08-12 Peppercoin, Inc. Procede et systeme de traitement de micro-paiements
US20060080238A1 (en) * 2004-08-30 2006-04-13 Nielsen Thomas A Micro-payment system architecture
US20060149671A1 (en) * 2004-06-25 2006-07-06 Robert Nix Payment processing method and system
JP2007179362A (ja) * 2005-12-28 2007-07-12 Fujitsu Ltd 個人情報証明プログラム、方法、及び装置。

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6341273B1 (en) * 1997-03-26 2002-01-22 British Telecommunications Public Limited Company Electronic coin stick with potential for future added value
AU6862798A (en) * 1998-03-18 1999-10-11 Institute Of Systems Science A method of exchanging digital data
US6055508A (en) * 1998-06-05 2000-04-25 Yeda Research And Development Co. Ltd. Method for secure accounting and auditing on a communications network
US6789068B1 (en) * 1999-11-08 2004-09-07 At&T Corp. System and method for microbilling using a trust management system
IL150926A0 (en) * 2000-02-10 2003-02-12 Jon Shore Apparatus, systems and methods for wirelessly transacting financial transfers, electroniocally recordable authorization transfers, and other information transfers
US20040199475A1 (en) * 2001-04-27 2004-10-07 Rivest Ronald L. Method and system for micropayment transactions
EP1627488A4 (fr) * 2003-05-13 2008-06-04 Corestreet Ltd Systemes efficaces et surs d'indication de l'actualite de donnees
JP4830860B2 (ja) * 2005-01-21 2011-12-07 日本電気株式会社 署名装置、検証装置、証明装置、暗号化装置、及び復号化装置
US20070168297A1 (en) * 2006-01-18 2007-07-19 Cheng Siu L Efficient method and system for secure business-to-business transaction
US20070269040A1 (en) * 2006-05-16 2007-11-22 Microsoft Corporation Cryptographic Protocol for Commonly Controlled Devices
US20090328167A1 (en) * 2006-08-03 2009-12-31 O'mahony Donal Network access method and system
IL178488A0 (en) * 2006-10-05 2008-01-20 Nds Ltd Improved key production system
TWI340354B (en) * 2006-12-14 2011-04-11 Inst Information Industry System, method, and computer readable medium for micropayment with varying denomination

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20010068434A (ko) * 2000-01-05 2001-07-23 이임영 소액 전자상거래 방법
WO2004068293A2 (fr) * 2003-01-25 2004-08-12 Peppercoin, Inc. Procede et systeme de traitement de micro-paiements
US20060149671A1 (en) * 2004-06-25 2006-07-06 Robert Nix Payment processing method and system
US20060080238A1 (en) * 2004-08-30 2006-04-13 Nielsen Thomas A Micro-payment system architecture
JP2007179362A (ja) * 2005-12-28 2007-07-12 Fujitsu Ltd 個人情報証明プログラム、方法、及び装置。

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9871786B2 (en) 2015-07-23 2018-01-16 Google Llc Authenticating communications

Also Published As

Publication number Publication date
WO2009100112A3 (fr) 2009-11-05
US20090198619A1 (en) 2009-08-06

Similar Documents

Publication Publication Date Title
WO2009100112A2 (fr) Système agrégé de chaîne de hachage de micropaiement
US8983874B2 (en) Method and system for micropayment transactions
EP2367318B1 (fr) Gestion et distribution de la Facturation dans les réseaux sans fil
US7620606B2 (en) Method and apparatus for secure and small credits for verifiable service provider metering
JP4274770B2 (ja) 認証決済方法、サービス提供装置及び認証決済システム
US7783579B2 (en) Method and apparatus for secure and small credits for verifiable service provider metering
CN112292704A (zh) 交易处理
US20120089494A1 (en) Privacy-Preserving Metering
CN110851870A (zh) 基于可信执行环境的区块链隐私保护方法、系统及介质
WO2007082452A1 (fr) Système et procédé efficace pour transactions sécurisées entre entreprises
WO2020082414A1 (fr) Procédé et appareil d'émission de bon, dispositif informatique et support de stockage associés
JP4690075B2 (ja) サービスプロバイダとサービス利用者の間の争いを解決する方法およびシステム
US20080232590A1 (en) Micropayment Processing Method and System
CN113506106B (zh) 一种交易方法、结算方法及其装置和存储介质
Kher et al. Building trust in storage outsourcing: Secure accounting of utility storage
Zhu et al. A micro-payment scheme for multiple-vendor in m-commerce
JP4018370B2 (ja) 署名分散システム、プログラム及び方法
US20030225691A1 (en) Method and device for processing an electronic transaction
CN117455672A (zh) 一种基于区块链的存证交易方法、装置、设备以及介质
Kiyomoto et al. Implementation and evaluation of a micropayment system for mobile environments
Ring et al. A Secure Billing Architecture for 4G Wireless Networks
WP of Deliverable Secure billing: evaluation report
AU2002254649A1 (en) Method and system for micropayment transactions
KR20020069070A (ko) 이중 해쉬 체인을 이용한 전자 지불 시스템

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09707838

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09707838

Country of ref document: EP

Kind code of ref document: A2

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载