Thông tin tài liệu
in the following way. Instead of s (random and chosen by the guardian), s 0 + s 1 is used. s 0 is chosen by the purse, and s 1 by the guardian. Specifically, it means that in the protocol above the following values are used: ag p ss = + 01 mod bm p ss = + 01 mod () rsscx q=++ 01 mod It is done in such a way that only the guardian knows s. This type of signature is sometimes referred as the randomized signature. An additional difficulty is that it needs to be impossible to trace the wallet on the basis of the guardians identity. Therefore a mechanism is needed to obscure the origin of the guardians signature key. One such mechanism was proposed in [7]. 7.2.4.2 Issuers Signature To provide payment untraceability, the signature on the coin that the purse obtains from the issuer must be blind (similarly to that described in Section 7.1.1). The purse must blind both the message and the challenge from the basic signature described earlier. The protocol steps are then as fol- lows [7]: 1. Verifier→Signer mm p 0 1 = mod t random, 0 <<tq 2. Signer→Verifier ag pbm p s s 00 0 = mod , mod s random, 0 <<sq 3. Verifier→Signer blinded challenge ccu q 0 = / mod u random, 0 ≤<uq 4. Signer→Verifier blinded response () rscx q 00 =+ mod The unblinded signature of m is () ( )s mzabr= ,,, ; it can be computed by the verifier, but not by the signer: 108 Security Fundamentals for E-Commerce TEAMFLY Team-Fly ® zz p t = 0 1/ mod () aag p v u = 0 mod () bbm p tv u = 0 1/ mod () rrvu p=+ 0 mod After Step 2 the verifier chooses u and v randomly, 00<< ≤<uq vq, , so it can compute a and b, but the signer cannot since it does not know u and v. Similarly, after Step 3 the verifier can unblind the response r.Asinthe basic protocol, ()cHmzab= ,,, , which can be computed by the verifier only. On the other hand, if the purse generates electronic coins and wants to obtain a blind signature on the coins from the issuer, the issuer wants to be sure that the guardian has agreed to the coins. To demonstrate its agreement, the guardian signs the blinded challenge c 0 by using the randomizedbut not blindsignature protocol. Since the signature is randomized, the guard- ian cannot send a subliminal message to the issuer, but only z 0 . The issuer signs a blinded message m 0 only if the challenge is signed by the guardian. The protocol is a blind signature protocol as described earlier. Additionally, the signer (i.e., the issuer) is not allowed to choose s alone, but together with the purse, in much the same way as with the guardians randomized signature from the previous section. In this way the issuer cannot send a subliminal message to the guardian. The guardian can see all protocol parameters that the purse can, except s 0 . It cannot, however, send any of them to the issuer except c 0 , since the purse controls the communication with the outside world. Should the issuer ever get the guardian back and analyze the information from the signature protocols, it could see the unblinded messages and their signatures. In [8] an improvement of the protocols described so far is proposed, so that even if the issuer manages to collect the information from the guardian, it is impossible to trace the behavior of the payer. If the tamper resistance of the guardian is broken by the user, it is not possible to detect double spending just by using the protocols described above. One should additionally use a cut-and-choose mechanism, as described in Section 7.2.1, to detect double spending after it has occurred. A more efficient mechanism based on restrictive blind signatures is described in [9]. Digital Money Security 109 7.3 Protection Against Forging of Coins In general, it is quite difficult to forge traditional money. First, the notes must have special, expensive or difficult-to-reproduce physical features (e.g., special print or color). Second, the serial numbers must at least look genuine. Whether the serial numbers are actually fake can only be detected by check- ing at the legal money issuing authority. With digital money, physical repro- ducibility does not pose a problem. Serial numbers can be checked before spending only in online systems, but this is neither scalable nor practical. The only other option is to issue coins with serial numbers that have special mathematical properties. 7.3.1 Expensive-to-Produce Coins If it is expensive to produce low-value coins, or if it is necessary to make a large initial investment to set up coin production, coin forgery will not pay off. That is the rationale behind the MicroMint scheme by Rivest and Sha- mir [10]. Its property is that generating many coins is much cheaper per coin than generating a few coins. MicroMint is a credit-based off-line micropay- ment system. The basic scheme does not use public key cryptography, but only cryp- tographic hash functions. Specifically, a coin is represented by a hash func- tion collision. () xx x k 12 ,,,K is a k-way hash function collision if and only if the following holds true: () () () hx hx hx k 12 ===K k-way collision h(.) is a cryptographic hash function that maps m-bit inputs () xi k i ,,,=1 K to n-bit outputs (hashsums). The validity of the coin can be verified by checking that all x-values are distinct, and that all yield the same hashsum. Approximately () 2 1mk k− / x-values must be examined (i.e., hashed) in order to obtain the first k-way collision with a probability of 50%. If those examinations are repeated c times, c k k-way collisions can be expected. In other words, it is rather expensive to find the first collision, but it becomes increasingly cheaper to find further collisions. This result is based on the birthday paradox. In order to make computing of the first collision expensive enough, it is recommended that k > 2 . For additional security, the coins should be valid only for a limited time period (e.g., a month). The broker can also define an additional validity criterion at the beginning of each validity 110 Security Fundamentals for E-Commerce period, for example, a requirement that the higher-order bits of all valid coin hashums be equal to some predetermined value. 7.4 Protection Against Stealing of Coins An obvious way to protect digital coins from being stolen through eavesdrop- ping is to use encryption. However, coins usually have a rather low nominal value (e.g., up to 1 euro). Consequently, in many cases it would be rather inefficient and expensive to use an encryption mechanism. This section describes several other mechanisms that can serve the same purpose. 7.4.1 Customized Coins Coin customization places some restrictions on who can spend a coin. A sim- ple way to make a coin customized is to add customer identity information to it. However, it is understandable that customers sometimes prefer staying anonymous at the risk of losing some coins. In such cases the probability of stealing can be reduced by making the coin merchant-specific. 7.4.1.1 Customer-Specific and Yet Anonymous Coins The mechanism described here is from NetCash 3 [3], which is an online pay- ment system. A coin can be customized so that it can be used only by a spe- cific customer within a certain period of time. In addition, the mechanism preserves the customers anonymity, protects the merchant from double spending, and guarantees the customer a valid receipt or the return of the money. The corresponding protocol is illustrated in Figure 7.2. The protocol steps are denoted by 1 to 4, and CS stands for currency server. In Step 1, A sends coins to the currency server CS to obtain a coin triplet: Step 1: () E coins K E t t CS AN BBA ,,,, 1 Digital Money Security 111 CS Customer A Merchant B 1 2 3 4 Figure 7.2 NetCash protocol with customized coins. 3. See also Section 7.1.2 The message is encrypted with the currency servers public key E CS ,so only CS can read it. K AN1 is a symmetric session key that should be used by the currency server to encrypt the coin triplet sent in the reply (Table 7.1): Step 2: <>CCC XBA ,, Each coin in the triplet has the same serial number and coin value. B may spend the coin C B before time t B . If B wants to use the coin in a transac- tion with CS, B has to prove knowledge of the private key D B , since Bs pub- lic key E B is embedded in C B . If A decides to spend the coin with B, A sends the following message to B saying which service he is paying for (ServiceID): Step 3: () ECK K sesBB AN ServiceID,,, 2 In order to pair the coins with the connection, B retains the session key K ses . At the time the service is to be provided, B verifies that A knows K ses .B must convert the coin while it is valid (i.e., before time t B ). B is supposed to reply to the message in Step 3 with a signed receipt containing the transaction information (Amount, TransactionID) and a time stamp (TS), all encrypted with the symmetric session key K AN2 : Step 4: () () KD TS AN B Amount TransactionID 2 ,, If B does not send A a receipt, A can query the currency server and check whether B has spent the coin. If B has spent the coin, the currency server will issue a signed receipt to A specifying the coin value and Bs key. If B has not spent the coin, A can obtain a refund during the time in which C A is valid. A may spend coin C A after time t B and before time t A . If A decides not to spend the coin with () B B C but to use it in transaction with () CS C A , A has 112 Security Fundamentals for E-Commerce Table 7.1 NetCash Coin Triplet Coin May be spent by Validity period C B B Before t B C A AFrom t B to t A C X Anybody After t A to prove that it knows the private key D A , since As public key E A is embed- ded in C A . This key does not necessarily reveal As identity. Finally, C X is used if A does not spend the coin with B. It can be used by anyone since it has no key embedded in it. 7.4.1.2 Customer-Specific Coins Collisions MicroMint [10] proposes two different approaches for making coins customer-specific and easily verifiable by merchants. It uses no encryption at all. The main design goal was to provide cheap, reasonable security for unre- lated low-value payments. The first approach is to make a coin group-specific. A group consists of a number of users. It should not be too large, because in that case it would be possible to steal coins from one group member and sell them to another group member. The group should not be too small either, because this would require too much computing from the broker to satisfy all individual cus- tomer needs. The broker gives a customer a numerical ID and MicroMint coins (see also Section 7.3.1) satisfying the following additional condition, which can easily be checked by a merchant: () ()hxx x hID k 1 12 1 ,,,K = h(.) is a cryptographic hash function that produces short hashsums (e.g., 16-bit long). The hashsums indicate the customers group. The second approach uses a different, more complicated, type of colli- sion. The broker gives the customer a coin () xx k 1 ,,K such that the hashsums () () () yhxyhx yhx kk 112 2 == =,,,K satisfy the following condition: () yy d ii u i+ −= 1 2mod for i = 1, 2, , k−1, where () ()dd d hID k 12 1 ,,, 'K − = for a suitable auxiliary hash function h(.). If, in addition, customer-specific coins can be spent at a specific mer- chant only, stealing of coins becomes even less attractive. The reason is that the merchant can easily detect that the coin has already been spent for his Digital Money Security 113 goods or services. One approach, described in [10], is to make a coin customer-specific, and then have the customer make the coin merchant- specific. Hash Function Chains PayWord [10] is a credit-based payment system: a customer establishes an account with a broker that issues a digitally signed PayWord customers cer- tificate. Digital coins, called paywords, are customer-specific. The design goal was to minimize communication with the broker. PayWord is an off- line scheme, since the broker receives at regular time intervals (e.g., daily) only the last payword spent by each customer at each merchants. In the PayWord scheme, the coins are produced by customers, not by the broker. A customer creates a payword chain (w 1 , w 2 , , w n ) by randomly choosing the last payword w n and then computing () whw ii = +1 for in n=− −120,,,K w 0 is the root of the payword chain. When the customer wants to buy something from a merchant for the first time, he sends the root as a signed commitment to the merchant. In addition, he must send his PayWord cer- tificate issued by a broker willing to redeem his paywords. The certificate contains the customers public key with which the signature of the commit- ment can be verified. The customer is not anonymous. A payment consists of a payword and its index, that is () wi i , . At first payment the customer sends () w 1 1, to the merchant. The vendor checks whether the payword is valid by computing () whw o ' = 1 . w o ' must be equal to w 0 , that is, the commitment or the root of the payword chain. At the i-th payment the customer sends () wi i , , and the merchant verifies whether () whw ii− = 1 . 7.4.1.3 Customer- and Merchant-Specific Coins Millicent [11] is a family of online micropayment protocols by Digital (1995). The customer must contact the broker online each time he wants to interact with a new merchant. The protocols are designed for purchases of 50 cents and less, that is, mostly for buying electronic information such as online newspapers, magazines, or stock prices. In the Millicent model, the broker is the most trustworthy party, since it usually represents a reputable financial institution such as a bank. If cus- tomers and merchants cooperate, they can detect when the broker is 114 Security Fundamentals for E-Commerce cheating. Customers have the possibility to complain if merchants are trying to cheat. Customers need be trusted only if they complain about service problems. The model is based on three secrets: • master_customer_secret, used to derive the customer_secret from the customer information in the scrip (see below); it is known to the merchant and the broker. • customer_secret, used to prove the ownership of the scrip; known to the broker and the customer; it can be derived by the merchant from the master_customer_secret; it is computed as h(CustomerID, mas- ter_customer_secret). • master_scrip_secret, used by the merchant to prevent tampering and counterfeiting; it is known to the merchant and the broker. In the Millicent scheme a digital coin is called scrip. A scrip has a low value and can be spent by its owner (CustomerID) at a specific merchant only, so it is both customer- and merchant-specific. A scrip consists of a scrip body and a certificate. The scrip body contains the following fields: • Merchant, value, expiration date, customer properties; • Scrip ID (unique per scrip, used to select the master_scrip_secret); • CustomerID (used to produce the customer_secret). The scrip certificate is computed as h(scrip_body, master_scrip_secret). It actually represents the scrip authentication information in the form of the MAC. A scrip has a serial number (ID) to prevent double spending. However, if the scrip is sent in the clear, it can be stolen, although it is customer- specific. For example, an eavesdropper can intercept the scrip that is returned as change by the merchant (scrip) and use it later. To prevent stealing, Milli- cent uses purchase request authentication by applying a MAC. The MAC is computed as a hashsum of the purchase request, the scrip and a secret (cus- tomer_secret) shared between the broker, the customer, and the merchant. The merchant can derive the secret from the customer information in the scrip by using another secret that is shared between the merchant and the broker (master_customer_secret). The corresponding purchase protocol goes as follows: Digital Money Security 115 Customer→Merchant: scrip, request, h(scrip, request, customer_secret); Merchant→Customer: scrip, reply, h(scrip, certificate, reply, customer_secret). This protocol has the best security-performance trade-off of all Milli- cent protocols. The change scrip (scrip) has the same CustomerID as the scrip from the customers message. This means that the same customer_secret can be used to authenticate a purchase request in which scrip is used as pay- ment. The scrip certificate is included in the merchants response so that the customer can check which request it belongs to. References [1] Chaum, D., Blinding for Unanticipated Signatures, In Advances in Cryptology Proc. EUROCRYPT 87, pp. 227233, D. Chaum (ed.), LNCS 304, Berlin: Springer- Verlag, 1988. [2] Boly, J P., et al., The ESPRIT Project CAFE High Security Digital Payment Sys- tems, In Computer Security Proc. ESORICS 94, pp. 217230, D. Gollmann (ed.), LNCS 875, Berlin: Springer-Verlag, 1994, http://www.semper .org/sirene/publ/ BBCM1_94CafeEsorics.ps.gz. [3] Medvinsky, G., and B. C. Neuman, NetCash: A design for practical electronic cur- rency on the Internet, Proc. First ACM Conf. on Computer and Communications Secu- rity, Fairfax, VA, Nov. 35, 1993, pp. 102106. [4] Chaum, D., A. Fiat, and M. Naor, Untraceable Electronic Cash, In Advances in Cryptology Proc. CRYPTO 88, pp. 319327, S. Goldwasser (ed.), LNCS 403, Ber- lin: Springer-Verlag, 1990. [5] Shamir, A., How to Share a Secret, Communications of the ACM, Vol. 22, No. 11, 1979, pp. 612613. [6] Schneier, B., Applied Cryptography, New York, NY: John Wiley & Sons, Inc., 1996. [7] Chaum, D., and T. P. Pedersen, Wallet Databases with Observers, In Advances in Cryptology Proc. CRYPTO 92, pp. 89105, E.F. Brickell (ed.), LNCS 740, Berlin: Springer Verlag, 1993. [8] Cramer, R. J. F., and T. P. Pedersen, Improved Privacy in Wallets with Observers, In Advances in Cryptology Proc. EUROCRYPT 93, pp. 329343, T. Helleseth (ed.), LNCS 765, Berlin: Springer-Verlag, 1994. 116 Security Fundamentals for E-Commerce [9] Brands, S., Untraceable Off-line Cash in Wallet with Observers, In Advances in Cryptology Proc. CRYPTO 93, pp. 302318, D. R. Stinson (ed.), LNCS 773, Berlin: Springer-Verlag, 1994. [10] Rivest, R. L., and A. Shamir, PayWord and MicroMint: Two simple micropayment schemes, Proc. Fifth Annual RSA Data Security Conference, San Francisco, CA, Jan. 1996, pp. 1719. [11] Glassman, S., et al., The Millicent Protocol for Inexpensive Electronic Commerce, Dec. 1997, http://www.millicent.digital.com/works/details/papers/millicent-w3c4/ millicent.html. Digital Money Security 117 [...]... infrastructure (i .e. , a common communication network), for exchanging various types of information Currently this is 135 136 Security Fundamentals for E- Commerce not the case, so we have, for example, a public switched telephone network, a mobile telephone network, and the Internet However, there are already certain services that cross the boundaries between these networks For example, one can send an e- mail... are shown in square brackets in Figure 10.2 because they are not actually a part of the Internet but are frequently used to access the Internet The next higher layer, the Internet layer, is the core part of the Internet, as its name suggests The Internet Protocol [7] makes internetworking possible since it allows data to be sent between two hosts even if they are not 140 Security Fundamentals for E- Commerce. .. two nodes are located in geographically distant areas, there is usually no direct connection (link) between them Consequently, the data exchanged between the two nodes must traverse some intermediate nodes An intermediate node must therefore switch data from one link to another Often there are several possible paths between two distant nodes, each path involving a different set of intermediate nodes and... address the hosts in the network addressed by the first part IP messages are called IP packets The source IP address and the destination IP address of an IP packet are contained in the packet header Mapping between the IP addresses and the network access addresses (e. g., Ethernet or ATM (Asynchronous Transfer Mode) addresses) is handled by the ARP Reverse mapping is performed by means of the Reverse... differences between the OSI model and the Internet is the meaning of layering In the OSI model, a layer is basically allowed to use services of the next lower layer only and to offer services to the next higher level only In the Internet it is possible for two layers to cooperate directly, even if they are not adjacent [2] The term intranet is used to refer to an internal enterprise network, often disconnected... technique employed (e. g., Ethernet based on the IEEE 802.3 standard, or token ring from IEEE 802.5) The network access layer operates with medium-level host addresses, such as Ethernet addresses (e. g., 08 00 39 00 2F C3) The protocol messages exchanged at this layer are referred to as frames If the connection must be established over a telephone line, a dial-up protocol is used, such as PPP or SLIP These... the Internet to a mobile phone (e. g., via short message serviceWWW gateways, see Chapter 21) or access the Internet from the public switched telephone network (e. g., via PPP or SLIP, see Chapter 11), or make a phone call over the Internet (e. g., voice over IP1) 10.2 The OSI Reference Model One of the frequently used models for explaining the logical structure of a communication network is the 7-layer... the Merchant is copied to the Signature block This signature serves as proof to the Payment Handler that the Merchant agrees with the payment After the Payment Request message, one or more Payment Exchange messages can be exchanged between the Consumer and the Payment Handler This type of message serves to carry the underlying payment-protocolspecific data (e. g., SET) Finally, if everything has gone... the data transfer stream to allow backup and recovery The role of the OSI transport layer is to provide a reliable data exchange mechanism between processes running on different end systems It ensures that data units are delivered error-free, in sequence, and without losses or duplicates The network layer provides the so-called end-to-end connection between two systems In other words, even if the... granted the service All keys (except K C − S ) are known to the Kerberos server, and every server has to share a secret key with every other server 8.1.1.2 Restricted Proxy The Kerberos TGS ticket is in fact a restricted proxy The restriction is the time interval (t 1 , t 2 ) within which a ticket is valid A generalized form of restricted proxy can be written as follows: 122 Security Fundamentals for E- Commerce . Customers need be trusted only if they complain about service problems. The model is based on three secrets: • master_customer_secret, used to derive the customer_secret from the customer information. placed on its use. In the check example, the restrictions are the payee (designated customer), the amount of money to be paid, and the issue date. NetCheque proxies are based on Kerberos tickets. first part (service ticket). If the service ticket is valid, the client is granted the serv- ice. All keys (except K CS− ) are known to the Kerberos server, and every server has to share a secret key with
Ngày đăng: 14/08/2014, 18:21
Xem thêm: security fundamentals for e commerce phần 4 ppsx
