Digital Cash as an Alternate Payment Mechanism
Anonymous Electronic Commerce -
Digital Cash As An
Alternative Payment Mechanism
Submitted in partial fulfilment of the
Bachelor of Science (Honours)
degree of Rhodes University
Gareth Alan Howell
Computer Science Department
November 2000
Acknowledgements
To my family, for always supporting and encouraging me.
To my supervisors, John Ebden and Professor Peter Wentworth, for your guidance. Your ideas inspired me, and helped me to find direction and focus for this project.
To my girlfriend, Larine, for your love and encouragement (not to mention a good deal of proof reading).
To Professor Pat Terry, for lending me his exceptional proof reading skills. The time and effort he spent in correcting my grammar has greatly improved the standard of English in this project.
Lastly, to my saviour, Jesus Christ. You give me strength when I am weak, and courage when I am afraid. All the glory is yours.
Abstract
Credit cards are the only widely used means of payment on the Internet, but not everyone is eligible for a credit card, the per-transaction cost is high, and electronic transmission and storage of card details pose significant fraud and privacy risks. As more commerce moves onto the Internet, new payment systems need to be deployed that can support all forms of transactions. In the virtual world, the payment systems available to us should at least equal those that are available in the physical world. To achieve this we need an electronic equivalent to cash, which will allow for relatively cheap and anonymous transactions on the Internet. Many digital cash systems have been developed which allow for anonymous payments, yet determining what features we need, let alone what we are capable of implementing, is often confusing.
In this project we describe the key attributes of digital cash, and ways in which we can implement these attributes. Having examined the theory and analysed some current proposals, we adapt some existing classification schemes in the literature to produce our own classification scheme for electronic payment mechanisms, and digital cash in particular. We then consider a case study, the Rhodes University campus, classify the requirements in terms of our model, and use this framework to make recommendations for an electronic payment system on campus.
Contents
1 Introduction 1
2 Cryptography – A Look Behind the Scenes 5
2.1 Terms and Definitions 5
2.2 Symmetric Algorithms 6
2.3 Asymmetric Algorithms 8
2.3.1 Web of Trust 11
2.3.2 Certification Authorities 11
2.4 Hybrid Cryptosystems 12
2.5 Hash Functions 13
2.6 Digital Signatures 14
2.7 Bit Commitment 18
2.8 Secret Splitting 19
2.9 Review 20
3 The Mathematics of Digital Cash 21
3.1 RSA – A Public-key Cryptosystem 21
3.1.1 Generating a Key-pair in RSA 22
3.1.2 Encryption with RSA 22
3.1.3 Decryption with RSA 23
3.1.4 Issues in Public-key Cryptosystems 23
3.2 Blind Signatures 24
3.3 Review 25
4 What is Digital Cash? 26
4.1 Key Attributes of Digital Cash 26
4.1.1 Secure 27
4.1.2 Anonymous 27
4.1.3 Off-line capable 30
4.1.4 Portable 31
4.1.5 Two-way 32
4.1.6 Infinite Duration 33
4.1.7 Divisible 35
4.1.8 Widely Accepted 36
4.1.9 User-friendly 36
4.1.10 Unit-of-Value freedom 36
4.2 Optional Attributes of Digital Cash 38
4.2.1 Micropayments 38
4.2.2 Conditional Repudiation and Recovery 38
4.2.3 Scalable 39
4.3 Review 40
5 Achieving Digital Cash 41
5.1 Tamper Resistant Smart Cards 41
5.2 Developing a Digital Cash System 42
5.2.1 Secure 43
5.2.2 Anonymous 45
5.2.3 Off-line capable 48
5.2.4 Portable 53
5.2.5 Two-way 54
5.2.6 Infinite duration 55
5.2.7 Divisible 55
5.2.8 Widely Accepted 57
5.2.9 User-friendly 57
5.2.10 Unit-of-Value freedom 58
5.2.11 Micropayments 58
5.2.12 Conditional Repudiation and Recovery 59
5.2.13 Scalable 60
5.3 Review 61
6 iKP and SET – NOT Digital Cash 62
6.1 What is iKP? 62
6.1.1 iKP Security Levels 63
6.1.2 1KP Protocol 65
6.1.3 2KP Protocol 67
6.1.4 3KP Protocol 68
6.2 What is SET? 69
6.2.1 Benefits of SET 69
6.3 What About Digital Cash? 70
6.4 Review 70
7 Recommendations for Rhodes Campus 71
7.1 Analysis of Requirements 72
7.1.1 Small Payments 72
7.1.2 Large Payments 73
7.1.3 Classifying the Requirements 75
7.2 Designing a System 75
7.2.1 Quick Overview of PayMe 75
7.2.2 Designing for Requirements 76
7.3 Designing for Large Payments 78
7.3.1 Off-line 78
7.3.2 Partial Anonymity 79
7.3.3 Bursar Requirements 79
7.3.4 Peer-to-Peer Payments 80
7.3.5 Loading Cash 81
7.3.6 Depositing Cash 81
7.4 Concerns 82
7.5 Looking Ahead 83
7.6 Review 84
8 Conclusions and Future Research 85
8.1 Conclusion 85
8.1.1 Rhodes University 86
8.2 Future Research 88
References 89
Appendix A: Bibliography 92
Cryptography 92
Digital Cash 93
E-Commerce 93
Economic Issues 95
Mathematics 98
Political Issues 98
Security 99
General 100
Glossary 103
Index 111
List of Figures
Figure 1-1: Electronic payment systems 2
Figure 2-1: Encryption and decryption 6
Figure 2-2: Securing communication with a secret-key algorithm 7
Figure 2-3: Securing communication with a public-key algorithm 9
Figure 2-4: Man-in-the-middle attack 10
Figure 2-5: Encryption in a hybrid cryptosystem 13
Figure 2-6: Decryption in a hybrid cryptosystem 13
Figure 2-7: Digitally signing a message 16
Figure 2-8: Signing a message using one-way hash functions 17
Figure 6-1: 1KP Protocol 66
Figure 6-2: 2KP Protocol 67
Figure 6-3: 3KP Protocol 68
List of Tables
Table 6-1: iKP Security Levels 64
Introduction
“It is plausible that we could soon be living in a world without expectation of privacy, anywhere or at any time.”
- Bruce Schneier
For thousands of years man has used some form of money as a means of trading. Tokens representing value, such as seashells, beads, and coins, have all been used as payment for goods or services. These tokens, which have been gradually replaced by government issued tender, have become our means of storing wealth. Over the last hundred years, a plethora of payment methods (including credit cards and cheques) have found their way into the consumer market, enabling us to use this wealth in new and innovative ways.
With the advent of the Internet, it became necessary for us to create payment mechanisms which allow for the electronic transfer of value. Although banks have been using electronic fund transfer (EFT) for many years, this approach is not suitable for consumer transactions in general. To date, there have been many systems developed which allow value to be transferred over the Internet, each offering different levels of security and anonymity, and different sets of features. Some of these systems share common features, but there is no general classification of these features available. The classification system adapted from [Grabbe, 1998c] helps us to better understand the landscape of electronic payments.
Figure 1-1 depicts the three categories of electronic payment systems available today, as well as specific implementations that fall within those categories.
• Secure credit card transactions transmit credit card numbers securely over an open network (such as the Internet). These systems use the existing credit card network to process payments.
• Credit-debit systems allow a user to open an account on a payment server, and authorise payments against this account. Depending on whether the account is allowed to have negative balance or not, it is called a credit or debit system.
• Digital token systems allow a user to purchase digital tokens and use these tokens as they would use cash. The tokens themselves represent value, just as bank notes and coins represent value.
[pic]
Figure 1-1: Electronic payment systems
Coins have traditionally carried their own value in gold, silver, or copper, whereas notes carry a promise from an underwriter (such as a government or bank) to redeem the note for value. The physical value of bits is negligible, thus any digital token system would more closely resemble paper cash – it can be no more than a promise to redeem a digital token for value. The term ‘digital coin’ is used in the literature to refer to a single digital token that can be redeemed for value. It does not imply that the token carries its own value, as a physical coin would.
In the virtual world, the payment systems available to us should at least equal those that are available in the physical world. Each of the categories in Figure 1-1 has an analogous payment mechanism in the physical world. To complete the picture, we need an electronic equivalent to paper cash, which would allow for anonymous transactions on the Internet. The terms ‘digital cash’, ‘e-cash’, and ‘electronic cash’ are used interchangeably to refer to an electronic equivalent to paper cash. They form a subset of the digital token systems in Figure 1-1.
In this project we explain what digital cash is, and how to achieve it. Having examined the theory and analysed some current proposals, we adapt some existing classification schemes in literature to produce our own classification scheme for electronic payment mechanisms, and digital cash in particular. We then consider a case study, the Rhodes University campus, classify the requirements in terms of our model, and use this framework to make recommendations for an electronic payment system on campus.
Our discussion about digital cash proceeds as follows:
Chapter 2 is an introduction to basic cryptography, including how public-key cryptography and digital signatures work. Cryptography is used in almost every secure electronic payment system, and is an essential component in protecting against fraud and providing anonymity, thus a basic understanding of it is important.
Chapter 3 looks at the mathematics behind some of the algorithms necessary to implement digital cash. These algorithms form the core of digital cash, and are also discussed at a higher level in Chapter 5.
Chapter 4 presents a detailed description of what attributes an electronic payment system must satisfy in order to be considered digital cash. These attributes are fairly general, and help determine the quality of proposed digital cash systems.
Chapter 5 discusses ways in which we can achieve some of the attributes of digital cash presented in Chapter 4. No system exists which satisfies all the criteria of Chapter 4, but properties of systems that satisfy some of the criteria are discussed.
Chapter 6 presents an overview of the iKP, a family of protocols developed by IBM to allow for secure credit card transactions on the Internet. iKP is then contrasted with digital cash systems. This is important because it presents a broader overview of electronic payment schemes, and helps clarify digital cash. By the end of this chapter we are in a position to adopt and motivate the classification shown in Figure 1-1.
Chapter 7 is a case study, which draws on all the previous chapters to make a recommendation for an electronic payment system that might be used on the Rhodes University campus.
Chapter 8 concludes by summarising what we are capable of doing with digital cash, and the areas that still need more research.
Cryptography – A Look Behind the Scenes
“Without cryptography, e-commerce could never enter the mainstream.”
- Bruce Schneier
Cryptography is the most basic building block of any secure transaction. It provides us with confidentiality (hiding of message contents), authentication (determining the origin of a message), integrity (verifying that a message has not been modified in transit), and non-repudiation (not allowing a sender to deny that he sent a message) [Schneier, 1996]. It gives us a virtual envelope in which to hide our message, and a virtual pen with which to sign it.
1 Terms and Definitions
The content of a message is called the plaintext, or cleartext. Sending a message in plaintext is like writing all your correspondence on the back of a postcard – it is easily readable by anyone. Encryption is the process that allows us to hide the contents of a message. Plaintext is encrypted to produce ciphertext, which can then be decrypted to reproduce the original plaintext [Schneier, 1996].
A cryptographic algorithm, or cipher, is a mathematical function used to encrypt plaintext and decrypt ciphertext. Two separate algorithms are normally used for encryption and decryption. Modern cryptography has learnt the hard way that strong encryption should not depend on the secrecy of the cryptographic algorithm. A key is used together with the cryptographic algorithm, making the encryption and decryption dependent on this key. The length of the key is important in order to prevent brute force attacks on the cipher. A brute force attack is one where every possible key in the keyspace (range of all possible values of a key) is tried until the correct decryption is found. A longer key makes it more difficult to launch a brute force attack, but also makes encryption and decryption take longer[1] [Schneier, 1996].
We denote the plaintext of a message by m, and the ciphertext by c. EK(m) denotes the encryption of a plaintext message m with respect to a key K. DK(c) denotes the decryption of the ciphertext c with respect to a key K. Thus,
DK(EK(m)) = DK(c) = m
for a cipher that uses the same key for encryption and decryption.
Figure 2-1 [Network Associates, 1999] illustrates the process of encrypting plaintext to produce ciphertext, and decrypting the ciphertext to reproduce the plaintext.
[pic]
Figure 2-1: Encryption and decryption
2 Symmetric Algorithms
The first type of key-based cryptographic algorithm is a symmetric algorithm. In such an algorithm, the encryption key can be calculated from the decryption key, and vice versa. In most symmetric algorithms, the encryption and decryption keys are the same. These are called secret-key algorithms. The security of the algorithm is achieved by keeping the key secret [Schneier, 1996]. In a secret-key algorithm:
EK(m) = c
DK(c) = m
Symmetric algorithms are good for encrypting one’s own files, but less useful for encrypting messages to other people. This is because both the sender and receiver have to agree on a secret key before they can communicate securely. In order to do this they need a secure channel over which to transmit the key. Figure 2-2 [Menezes et al, 1996] shows how Alice uses a secure channel to agree on a key with Bob, which is then used to encrypt messages over an unsecured channel, monitored by an adversary who wants to read their messages.
[pic]
Figure 2-2: Securing communication with a secret-key algorithm
3 Asymmetric Algorithms
Asymmetric algorithms, or public-key algorithms, are the second type of key-based algorithms, and use a different key for encryption and decryption. The decryption key cannot be calculated from the encryption key, and vice versa. The encryption key is called the public key, and the decryption key the private key. This is because the encryption key is often made public, while the decryption key is kept secret [Schneier, 1996]. The current public-key algorithms rely on a small set of number theoretic problems, such as factorising large prime numbers, and taking discrete logarithms[2]. In a public-key algorithm, with the public key denoted by K1, and the private key by K2:
EK1(m) = c
DK2(c) = m
but DK1(c) ≠ m
Public-key algorithms solve the problem of needing a secure channel to communicate. There is no need to agree on a secret key before communicating, as the public key (which is used to encrypt data) can be known by anyone. The sender just needs to be apprised of the recipient’s public key in order to begin secure communication. The sender encrypts the message with the recipient’s public key, and only the owner of the corresponding private key can decrypt the message. Figure 2-3 [Menezes et al, 1996] shows how Alice uses an unsecured channel to retrieve Bob’s public key, which is then used to encrypt messages to Bob over an unsecured channel. In this case, as before, the adversary is passive, and does nothing more than try to read Alice’s message to Bob.
[pic]
Figure 2-3: Securing communication with a public-key algorithm
There is more to public-key encryption than this, as an adversary is not always passive, and can launch a particularly devious form of attack called a man-in-the-middle attack. In this attack, (depicted in Figure 2-4 [Menezes et al, 1996]) the adversary (call him Mallet[3]) fools Alice into believing that she has downloaded Bob’s public key, when in fact she has downloaded Mallet’s public key. Meanwhile, Mallet downloads Bob’s actual public key. Mallet now intercepts any communication from Alice to Bob, and is able to decrypt it, read it, and even modify it. To avoid suspicion, Mallet can re-encrypt the message with Bob’s real public key, and send it to him [Menezes et al, 1996]. If Mallet is also able to trick Bob, by getting Bob to download Mallet’s public key when he thinks he has downloaded Alice’s, then he is able to monitor (and modify) all communication between Alice and Bob without ever being discovered. Both Alice and Bob believe that their communication is secure, not knowing that Mallet is able to read, modify, and delete any message.
[pic]
Figure 2-4: Man-in-the-middle attack
In order to prevent this kind of attack, Alice could get Bob’s key directly from him. If she knew him, and they lived close to each other, Alice could get Bob’s public-key from him on disk, and be certain that it was his. PGP, a popular email encryption program, allows Alice to check over the phone whether she has received Bob’s real public key [Network Associates, 1999]. This assumes that Alice knows Bob’s phone number and would recognise his voice, otherwise our adversary would merely have to pose as Bob over the phone. Both of these techniques are not suitable for securing communication on the Internet, where most communication takes place between people who have never met in person before.
Two solutions have been proposed to solve this problem:
1 Web of Trust
PGP uses a web of trust to help someone determine whether a public key belongs to a particular person [Network Associates, 1999]. To illustrate this, presume that Alice knows Carol, but does not know Bob, and that Carol knows both Alice and Bob. Alice knows Carol’s public key, and Bob knows Carol’s public key. Carol knows both Alice’s and Bob’s public key. If Alice trusted Carol, she could ask Carol whether the key she downloaded was actually Bob’s key[4]. Once Alice is sure of Bob’s public key, she may even choose to trust Bob to introduce her to other people (i.e. attest that their public keys are authentic). Eventually a network of people develops, where each person would trust certain other people to introduce them to new people – this is called a web of trust.
2 Certification Authorities
The second way to prevent man-in-the-middle attacks makes use of certification authorities. Certification authorities (CAs) bind a person’s name to a particular public key. This is done by bundling the person’s name, public key, expiry date, and various other information into a certificate, which the certification authority signs[5]. The CA is responsible for checking up on the person’s identity, to ensure that they are who they say they are. Bob can then show his certificate to Alice, and presuming she trusts the CA, he can prove that he is not an impostor trying to imitate Bob. Most browsers already have the public key of the CA (many of them, in fact) built into them, so there is no problem in verifying the CA’s signature[6].
It is possible that Bob could lose his private key, or that someone could steal it. A certification authority also maintains a certificate revocation list (CLI). If Bob loses his private key, he can contact the CA, and get his certificate put on the CLI. It is up to Alice to check the CLI to ensure that Bob’s certificate has not been revoked. This ensures that it is impossible for someone to steal Bob’s private key and pose as him indefinitely.
4 Hybrid Cryptosystems
Public-key encryption is a lot slower than secret-key encryption (by orders of magnitude)[7], and is thought to be less secure [Menezes et al, 1996]. This has led to the development of ‘hybrid’ cryptosystems. A hybrid cryptosystem uses public-key encryption to create a secure channel to transfer a session key. The session key is a key for a secret-key algorithm, and is used to encrypt messages between the sender and receiver for the duration of the session[8]. This allows us to benefit from the speed of secret-key encryption, and not need to worry about setting up a secure channel to transfer the key. Figure 2-5 [Network Associates, 1999] illustrates how encryption works in a hybrid cryptosystem, while Figure 2-6 [Network Associates, 1999] illustrates the corresponding decryption.
[pic]
Figure 2-5: Encryption in a hybrid cryptosystem
[pic]
Figure 2-6: Decryption in a hybrid cryptosystem
5 Hash Functions
A hash function is a mathematical function that takes a variable-length input (message), and produces a fixed length output (message digest), typically 128 or 160 bits in length. A one-way hash function has the additional property that it is easy to compute the ‘hash value’ (message digest) of a message, but difficult (computationally) to produce a message that hashes to a particular message digest. A good one-way hash function is also collision-free, in that it is difficult to generate two messages that hash to the same message digest [Schneier, 1996].
Even though many messages may have the same message digest, the properties of a one-way hash function allow us to effectively associate a unique message with a particular digest. We are able to do this because of the difficulty in finding another message that would hash to the same message digest. It is easy (computationally) for anyone who owns a document to verify whether it hashes to a particular value, by performing the hash, and comparing the results. Any change in the document, even a single bit, results in a completely different message digest.
6 Digital Signatures
Up until now, we have explained how to hide digital messages inside a digital envelope by using secret-key and public-key encryption. Digital signatures give us a digital pen with which to sign our digital messages.
In order for any signature scheme to be of use, it must first satisfy five properties [Schneier, 1996]:
• It must be impossible to forge another person’s signature.
• Anyone should be able to verify that a signature is authentic.
• It should be impossible to take a signature from one message, and use it on another message.
• Once a message has been signed, it should not be possible to alter it without invalidating the signature.
• It should not be possible for the signer to repudiate the signature, by later claiming that he did not sign the message.
In the physical world this works, more or less. Aside from a few devious people willing to spend time learning how to forge someone’s signature, most people cannot forge another person’s signature. A store clerk can easily verify that a signature is authentic, by comparing the signature on the transaction slip with that on the back of the credit card. It is possible, if difficult, to lift a signature from one message, and plant it on another message. We are normally able to detect this in the physical world, however. Any alterations made to a signed document are signed as well, otherwise the document is invalid (this is especially true for cheques). The law is used to solve any issues regarding repudiation[9].
Recall, that in public-key cryptography there are two keys used, a public and a private key. Anything encrypted with the public key can be decrypted with the private key. In some public-key cryptosystems, the reverse is also true – anything encrypted with the private key can be decrypted with the public key. Recall also, that the public key can be viewed by anyone (available on a web site, for example), and that the private key is only known by the owner of the public/private-key pair.
Signing a message digitally can be done by encrypting it with the private key to produce ciphertext. Much like a traditional signature, a private key is known to only one person[10]. Since the corresponding public key is widely known, we can verify the signature by decrypting the ciphertext with the public key. If the signature was authentic we obtain the original message that was signed, otherwise the message produced looks like random bytes. The message and the signature are essentially one entity, thus it is impossible to separate them, and impossible to alter the document without destroying the signature. Since we do not need the signer to verify the signature, it cannot be repudiated [Schneier, 1996]. Figure 2-7 [Network Associates, 1999] illustrates the process of digitally signing and verifying a plaintext message.
[pic]
Figure 2-7: Digitally signing a message
While this can work in practice, encrypting the whole message is slow, and doubles the size of the message being signed [Network Associates, 1999]. Recall that the one-way hash of a message can be effectively associated with a unique message. This means that signing the message digest (encrypting it with the private key) is as good as signing the actual document. Since the message digest is only 128 bits, it is much quicker to sign than the whole message, and the size of the overall message (including signature) produced is smaller. Figure 2-8 [Network Associates, 1999] illustrates the process of hashing the message, signing the message digest, and sending the signed digest along with the message. Verification of the signature simply requires verifying the signature on the message digest, and hashing the message to ensure that the digest signed is the correct one. It is impossible to transfer the signed digest to another message, because that message does not hash to the same digest value. Any alterations in the message also change the hash value, so a message cannot be altered after it is signed. The signed message digest of a particular message is referred to as the digital signature [Schneier, 1996].
[pic]
Figure 2-8: Signing a message using one-way hash functions
Digital signatures are used to ensure authenticity, integrity, and non-repudiation. Signing a message ensures authenticity. Since only one person knows the private key needed to sign the message, they must have signed the message. This also ensures non-repudiation, since a person cannot deny that they signed the message, as only they are capable of signing the message[11]. Hashing a message and signing the message digest produced allows the recipient of a message to check its integrity. This can be done by verifying the signature on the digest, and then hashing the message to ensure that the resulting digest is the same as the signed digest. If an adversary has tried to modify the message, the message will not hash to the same value as the signed hash value.
7 Bit Commitment
Suppose Alice wants to convince Bob that she can predict which horses will win their races on race day. Bob is sceptical, and wants Alice to tell him who will win the next race, so that he can be sure she is able to predict a winner. Alice wants to charge Bob for her services, and is afraid that if she told Bob which horse would win, Bob would bet on that horse, and not pay her. The solution in real life would be to put Alice’s prediction in a sealed envelope, and open the envelope after the race.
The solution in the digital world is to use encryption (our envelope) to hide the prediction, and then decrypt (open the envelope) the prediction after the fact. This is called bit commitment. There is a caveat, however. If Alice encrypted her prediction with a key K as EK(raindancer)and gave it to Bob, she would have a chance to try decrypting EK(raindancer) with various other decryption keys. She might even be able to find a decryption key K1 such that DK1(EK(raindancer))= moonshine, so if either raindancer or moonshine won the race, Alice would be able to convince Bob that she had predicted correctly, when in actual fact she cheated. It is even easier for Alice to cheat if she is just committing to one or two bits (as opposed to a word).
The solution is for Bob to give Alice a random bit-string to be encrypted together with her bit commitment. That way, if Alice wants to cheat, she needs to find a decryption key which not only produces a prediction that is different from her original one (and valid), but also produces Bob’s random bit-string exactly. The chances of Alice finding a decryption key to do this are minuscule [Schneier, 1996]. The full protocol looks like this [Schneier, 1996]:
1. Bob generates a random bit-string R, and sends it to Alice.
2. Alice creates a message containing the bit she wishes to commit to (or series of bits), b, and Bob’s random bit-string. She encrypts it with some key K, and sends the result, EK(R,b), to Bob.
3. Bob cannot decrypt the message, so he does not know the bit Alice committed to. When Alice must reveal her bit to Bob, she sends him the key.
4. Bob decrypts the message, revealing Alice’s committed bit. He checks that his random string is decrypted as well, to verify the bit’s validity.
If it is inconvenient for Bob to first generate a random bit-string every time, a pre-arranged bit-string can be used. Provided the bit-string is long enough, it will prevent Alice from cheating [Wayner, 1996].
8 Secret Splitting
For some applications, we need to split a secret between two people in such a way that neither person has any idea what the secret is, without knowing the other person’s half of the secret. An example could be splitting a secret key between two people. If it is a 64-bit key, giving one person the first 32 bits and the other person the second 32 bits will not work. Each person would be able to use their 32 bit half of the key in conjunction with a brute force attack on the remaining 32 bits to retrieve the whole key.
There is a relatively simple way to split secrets. The XOR (Exclusive OR) function is a bitwise mathematical operator, with the property that if A XOR B = C, then
A XOR C = B, and B XOR C = A. To split a secret using the XOR function we proceed as follows:
If S is an n-bit secret, we choose a random n-bit number, R, and set A = S XOR R. The secret is thus split into A and R, and is recovered by XORing them, because A XOR R = S. Splitting a secret like this has the added property that anyone in possession of just A or just R has absolutely no information about S [Schneier, 1996].
There are variations which allow a secret to be split between n parties, and allow any m < n split secrets to combine to reform the original secret, but these are not needed in this project.
9 Review
In this chapter we have discussed the basics of cryptography. Symmetric algorithms use similar encryption and decryption keys, so these keys must be kept secret. Asymmetric algorithms use a public key to encrypt data, and a private key to decrypt the data. Only the private key must be kept secret, whereas the public key should be made known to everyone. Both forms of encryption algorithms are used to provide confidentiality when sending messages.
Hash functions transform a variable length input, such as a message, into a fixed length output. It is difficult to find a message that hashes to a particular hash value using a one-way hash function, and difficult to find two messages that hash to the same value if the one-way hash function is collision-free. We can sign a message by encrypting it with the private key part of an asymmetric algorithm. This allows anyone with access to the corresponding public key to verify that it was signed (encrypted) with the private key. In order to speed up computation a one-way hash of the message is signed instead of the whole message. This is as good as signing the actual message, owing to the properties of one-way hash functions. In doing this we produce a digital signature, which is a signed hash of a message. Digital signatures are used for authentication, to ensure integrity, and to provide non-repudiation of messages.
A bit commitment protocol is used to commit to a prediction that is later going to be revealed. Once a prediction has been committed to, it is impossible to change it. Secret splitting is used to split a secret into two parts, such that neither part provides any information about the secret alone.
The Mathematics of Digital Cash
“This grand book, the universe, is written in the language of mathematics.”
- Galileo Galilei
We are now in a position to understand the basic concepts of cryptography, yet we still have no idea how any of the algorithms work. To gain a deeper insight into how cryptography enables us to create digital cash, we need to take a closer look at the inner workings of the algorithms. In particular, the mathematics used to achieve public-key cryptosystems is of interest. Provided it is secure, the choice of symmetric algorithm does not influence the workings of a digital cash system significantly. Likewise, provided a one-way hash function has the properties mentioned in section 2.5, the choice of hash function is irrelevant.
1 RSA – A Public-key Cryptosystem
The RSA public-key cryptosystem and signature scheme was developed in 1978, and named after its developers, Rivest, Shamir, and Adleman. It is based on the hard[12] mathematical problem of factoring large integers. Even with recent developments in Mathematics and Computer Science, factoring large integers remains an intractable problem [Menezes et al, 1996]. This is how RSA works [Wayner, 1996]:
1 Generating a Key-pair in RSA
1. Choose two large numbers (in the range of 500-2000 bits) at random[13]. Test these numbers to see whether they are prime. If not, choose new numbers until we have two large primes, p and q.
2. Multiply the primes together to get n = pq. n will form part of both the private and public keys.
3. Choose part of the secret key, e, such that e < (p-1)(q-1), and the greatest common denominator of e and (p-1)(q-1) is 1.
4. Calculate part of the public key, d, such that d < (p-1)(q-1), and
ed = 1 mod (p-1)(q-1).
5. Discard p and q since knowledge of p and q would enable anyone to easily obtain e for a given d.
6. (n,d) is the public key, and can be widely published. (n,e) is the private key, and should be kept secret.
2 Encryption with RSA
1. If the size of the message is larger than n we need to divide the message into blocks of size m < n. To illustrate encryption and decryption we assume that the message is of size m < n. Since many bytes can be represented by one large number, we take m to be the value of the message itself, which we convert back to characters after decryption.
2. Encrypt the message m, to get the ciphertext c = md mod n.
3. Send the ciphertext c over the network.
3 Decryption with RSA
1. Receive the ciphertext c, and use our private key (n,e) to decrypt it into a plaintext message m.
2. Decryption takes place by raising c to the power e, mod n:
ce mod n = (md mod n)e mod n
= mde mod n
Since ed = 1 mod (p-1)(q-1)from step 4 above
mde mod n = m[x*(p-1)(q-1) + 1] mod n (x is any positive number)
= (m mod n)*(m[x*(p-1)(q-1)] mod n)
= m mod n (by Euler’s Theorem [Koblitz, 1994])
3. Since we chose m < n we have not lost any information. m is the original plaintext message.
4 Issues in Public-key Cryptosystems
The same procedure as above is used to sign a message. The only difference would be in using our private key to encrypt, and the public key to decrypt the message.
As mentioned earlier, the security of the RSA algorithm is based on the difficulty we have in factoring large numbers. If we could find a computationally feasible way to factor large numbers, we could easily factor n to produce p and q, and thus e and d.
RSA is not the only public-key cryptosystem available, ElGamal is another public-key cryptosystem. It is based on the discrete logarithm problem [Menezes et al, 1996].
2 Blind Signatures
A blind signature is created when we digitally sign something without knowing what it is we are signing. At first glance this seems useless, for why would we want to sign something without first seeing it? In Chapter 5 we use the concept of a blind signature to develop a true digital cash system, but for now we are more concerned with the mathematics behind blind signing.
Here is the scenario:
Alice wants Bob to sign a message m without knowing the contents of the message, such that Bob’s signature on the document is valid. Furthermore, Bob should not be able to link the signed message with the act of signing the message [Schneier, 1996].
Let H(m) represent the hash of the message m. If Alice could get Bob to sign H(m), then Bob would sign the message without knowing what he was signing. The problem is, if Bob stores H(m) he is able to link the message m to the act of signing it (if Alice ever lets Bob see the message he signed). This is be done by calculating H(m) for all the messages Bob receives, and comparing it with each entry in his database containing the hashes of all messages he has previously signed.
The solution is for Alice to multiply the hash value by a blinding factor, which is just a random number. Let k represent the blinding factor, (n,d) be Bob’s public key, and (n,e) be Bob’s private key.
1. Alice sends Bob r = H(m)kd mod n (1≤k≤n)
2. Bob signs this by computing re = (H(m)kd)e mod n
3. Alice unblinds by multiplying by k-1:
rek-1 = (H(m)kd)e mod n * k-1
= (H(m)e kde) mod n * k-1
= H(m)e mod n * k*k-1 (Since kde mod n = k)
= H(m)e mod n
This is the signed hash value of the message, which is as good as a signed message. Therefore, Bob has signed the message without seeing the message, or its hash value [Wayner, 1996].
Even if Bob stores every transaction with Alice, he would still not be able to link any message to the signing of that message. This is because Bob does not know the blinding factor, k. If Alice reveals k to Bob, then he can link the signed message m, with the act of signing it.
3 Review
In this chapter we have seen some of the mathematics behind public-key cryptosystems. Specifically, we have looked at RSA, and how prime numbers are used to calculate the public and private keys. Blind signatures involve digitally signing something without knowing what it is we are signing. They have the added property that we are unable to associate the act of signing with a particular message, even if we have access to the message at a later date.
In Chapters 2 and 3 we explained basic cryptographic techniques, which serve as a foundation for the rest of the project. We now focus on electronic commerce, and digital cash systems in particular.
What is Digital Cash?
“You’ve got to be careful if you don’t know where you’re going, ‘cause you might not get there.”
- Yogi Berra
An easy answer to this question would be to say that digital cash is an electronic equivalent of traditional cash, with the same properties as cash. Yet, when we refer to the properties of traditional cash, we clearly are not concerned with the shape or colour of a note, the feel of the paper as you fold it into your pocket, or even the dirt that has collected on a well-used specimen. In some regards, we can think of digital cash as much more than just an electronic equivalent to paper cash.
Ease of spending, counting, and management – not to mention the fact that we don’t need to touch left over bits of someone’s lunch every time we use it – are just a few advantages that digital cash has over paper cash. But these properties are unimportant! Ease of use is a by-product of working in the digital world. In describing the properties of a true digital cash system, we use [Matonis, 1995] as a guide.
1 Key Attributes of Digital Cash
There are ten specific attributes that a true digital cash system must have. Although no currently available system satisfies all ten attributes, systems exist which satisfy some of the more important attributes. Not all attributes are desirable by everyone (indeed, the anonymity of digital cash is highly controversial), but all are necessary to match the properties of paper cash. Thus, a true digital cash system is:
1 Secure
When a government issues cash, they print it on a special kind of paper, and use watermarking and other techniques to ensure that it is difficult to counterfeit the notes. In order to be secure, a digital cash system should not allow anyone except authorised institutions to mint valid digital coins. Furthermore, it should allow anyone receiving a digital coin to easily check its validity. This is similar to holding a note up to the light to check its watermark.
Since a digital coin is just a collection of bits, we can easily make an exact copy. If it were a valid digital coin, there is no reason why the copy should be any less valid. We could then copy a coin and spend it as many times as we liked – this is called the double spending problem [Schneier, 1996]. A system that prevents double spending should also prevent a bank from framing someone by fraudulently claiming that they have double spent a coin.
The security of a digital cash system is its most important attribute. Without security, all the other attributes are meaningless, as the system would no longer serve as a medium for the exchange of value.
2 Anonymous
An anonymous transaction is both unlinkable and untraceable. A payment is unlinkable if the bank cannot determine whether two given payments were made by the same person. In the PayMe system [Peirce et al, 1995], if the bank colludes with the merchants it can link two payments to the same person. In order for a system to be unlinkable, a bank should not be able to do this. A payment is untraceable if the bank cannot match withdrawals of money with deposits of the same money. Law enforcement uses marked bills to defeat the unlinkability and untraceability of paper cash [Grabbe, 1998b].
Anonymity is a contentious issue, with civil liberties organisations arguing that privacy is a right, and that anonymous transactions are the only way to uphold this right on the Internet. Law enforcement agencies (and governments) are generally against anonymous transactions, because they say it aids in fraud and money laundering. Listed below are some of the issued raised by people who support anonymous transactions, and those who support traceable transactions.
Points in favour of anonymous transactions
• General monitoring of transactions at certain shops (such as gun shops, or even book stores) would be difficult. This forces a government to investigate only the select few people they suspect, rather than being able to easily investigate everyone. In a non-anonymous system, the government could easily compile a list of everyone who bought a hunting rifle, or a copy of Hitler’s ‘Mein Kampf’. [Froomkin, 1996] worries that people who purchase certain goods or information could then be subject to social control, such as private blacklisting.
• In a non-anonymous system, if highway tolls were to be collected electronically (they already are in some countries), the government could monitor owners of vehicles everywhere they went [Grabbe, 1998a].
• In the absence of anonymous digital cash systems, governments could compile huge databases, with very little effort, which contain information about every citizen. This information could include: everything we’ve ever bought, everywhere we’ve ever been, and perhaps even everything we’ve ever read. Anonymity would prevent Big Brother [Orwell, 1967] from watching over our shoulder at every transaction.
• Governments are trusted to some degree, and the information they collect about us should be used for little more than to ensure that we have paid our taxes. What would happen if a malicious hacker were to gain access to the government’s database of information? Are we willing to let an unscrupulous stranger know where our children go to school, or when last we visited a psychologist?
Points in favour of traceable transactions
• In order for a country to provide protection, and other public services to its citizens, it needs to collect taxes and other similar revenues. The collection of taxes relies on an identifiable location. It is difficult for governments to collect taxes if anonymous transactions can take place in unidentifiable international locations. [Grabbe, 1998a] wonders whether this would make taxes voluntary, which could have grave repercussions on our established social structures.
• Anonymous transactions could make money laundering much easier. In the U.S., banks accepting deposits of cash over $10 000 must disclose the identity of the depositor to the government. Regulations like this have made it more difficult for criminals to launder large amounts of cash. In the digital world such regulations would not work, because it is just as easy to deposit one amount of $10 000 as it is to make a $1 deposit 10 000 times [Bortner, 1996].
• Anonymous digital cash allows for ‘perfect crimes’ to be committed [Schneier, 1996]. An example of a perfect crime would be:
o Alice kidnaps a baby.
o Alice prepares 1000 anonymous money orders for $1000 each, and blinds them using a blind signature protocol.
o Alice threatens to kill the baby unless a bank signs all 1000 money orders and publishes the results in a newspaper.
o The authorities comply.
o Alice buys a newspaper, unblinds the money orders, and can start spending them. There is no way to trace the money orders to her.
o Alice frees the baby.
With physical cash, the police have a chance to apprehend Alice when she tries to get the cash, but in this scenario the police have no way of catching her, or tracking her down.
Tension exists between people who want a traceable digital cash system, and those who want their privacy protected by an anonymous system. [Clarke, 1996] proposes that pseudonymous transactions would satisfy both sides. A pseudonym is an identifier for a user, which is not normally sufficient to associate them with a particular person. A pseudonymous transaction is one in which the transaction data contains no direct identifier for anyone involved in the transaction – i.e. pseudonyms are used. By acquiring a specific piece of additional data, we can link the pseudonym to a particular person. This data could be stored in such a way that it would only be available if law enforcement presented a court order or warrant. This implies that we need a trusted third party (or parties) to act as an ‘identity escrow’, and store the mapping between pseudonyms and real names.
Regardless of whether or not anonymity is desirable, it is necessary if we are to match the properties of paper cash. Anonymity is the second most important attribute of a digital cash system. On the Internet, the way we use a secure, anonymous digital cash system would be almost indistinguishable from the way we use cash today. It is only when we move away from an interconnected set of computers that the other attributes become important.
3 Off-line capable
Digital cash systems are either off-line or on-line. An on-line system requires the merchant to clear each digital coin with the bank before accepting it. The bank then checks each coin to ensure that it has not been double spent, and notifies the merchant. An off-line system allows the merchant to accept digital coins without contacting the bank. Double spending is a problem in such a system. Chapter 5 looks at ways in which we can control double spending in an off-line system
An off-line system is essential in order to use digital cash for more than just Internet transactions. Connections to the bank are expensive, making an on-line system infeasible in some circumstances (Should a newspaper vendor be expected to contact the bank every time he sells a newspaper?). Some people argue that we are moving towards ubiquitous connectivity, where almost every device we own will be connected to the Internet in some way [Peirce et al, 1995]. Although this may be true in developed countries, it is not for most of Africa, where some people do not even have access to a telephone.
Even in a connected world, an on-line system has some drawbacks. If communication with the bank is broken, the merchant is not able to accept payments [Brands, 1994]. A large business on the Internet could lose hundreds of transactions for every minute that the connection is down. If the bank’s central computer is not able to cope with all the requests to authorise payments, there could be a queuing problem, resulting in delays for the consumer. Even if the connection to the bank is cheap, an on-line system is still too expensive to support micropayments, where merchants may want to charge a tenth of a cent for viewing a web page [Froomkin, 1996]. An off-line payment system would solve all these problems by allowing merchants to ‘bank’ once a day, freeing up communications networks and reducing the delays experienced by the consumer.
4 Portable
We can pick up a bank note, and take it anywhere we like, using it to purchase goods at any store in the country. In the same way, we should not need to be at our computer in order to spend our digital cash. If the digital cash is portable, it allows us to download the cash into a smart card (or other suitable device), and take it with us. The digital cash on our smart card also needs to be acceptable at traditional ‘brick-and-mortar’ stores. Any off-line capable system can easily be made portable by allowing the cash to be copied onto a smart card[14]. Indeed, there are strong expectations that mobile phones, which already have embedded smart cards, will become multi-functional portable devices. They could serve as digital cash wallets, personal identity cards, credit cards, and Internet connected mobile terminals. They also have a much greater market penetration than Internet connected computers.
We cannot use U.S. dollars to buy a newspaper in South Africa, which would mean any system that uses U.S. dollars would not be portable in South Africa (or even Internet sites that were based in South Africa). The Internet is not divided up geographically, so merely allowing us to spend U.S. dollars electronically would not be an ideal solution. A global currency is needed that will allow us to spend our digital cash anywhere on the Internet. The creation of a new currency will introduce problems when we tried to spend it in the physical world. We deal with this issue in section 4.1.10, where the concept of private value units is introduced.
5 Two-way
Paper cash allows us to give money to our friends directly. In order to be two-way, digital cash should allow users to exchange cash without first contacting the bank. Peer-to-peer payments should be possible without either party needing to register as a merchant.
Once again, there are factions here. Many existing digital cash systems require cash to flow up a hierarchy, from the consumer to the merchant to the bank (or other issuing institute). This means that once a digital coin is spent, it has to be deposited at the bank, and cannot be re-spent by the merchant. Traditional cash does not have this restriction.
Benefits of peer-to-peer payments
• Peer-to-peer payments are convenient. People exchange cash these days for all sorts of reasons, some of which are too trivial to warrant contacting a bank. (E.g. A father giving his child money to buy an ice-cream.)
• We are used to peer-to-peer payments. Taking away this ability will require us to undergo a paradigm shift in the way we think about money, which could meet with resistance.
Dangers of peer-to-peer payments
• Direct person-to-person transfer of value allows individuals to generate untraceable economic activity. This means that a government is limited in its ability to measure, let alone influence, the money supply. Governments use this ability to ensure that the economy does not overheat. Consider the situation where cash can only flow up a hierarchy, until it is eventually deposited in a bank. Only a small number of highly regulated institutions (such as banks) can re-inject the money into the economy, giving control of the money supply back to the government.
• [Bortner, 1996] worries that a digital cash system which allows peer-to-peer payments would make it easier to launder money. Criminals would no longer have to hide suitcases full of money, and would only have to worry about hiding a smart card full of illicitly obtained digital cash. [Froomkin, 1996] argues that our existing hierarchical digital cash systems (even anonymous ones) may make money laundering more difficult than with paper cash. Since the money would end up in a bank account after each transaction, it would be easy to determine the final destination of money.
The ability to track the level of economic activity is independent of the issue of anonymity.
6 Infinite Duration
It is still possible to spend bank notes that were printed ten or twenty years ago, as paper cash does not expire[15]. In a true digital cash system, [Matonis, 1995] proposes that it should be possible to store a digital token for as long as we wish before spending it. During this time the value of the digital token may fluctuate, depending on exchange rates.
Some systems, such as MicroMint [Rivest et al, 1998], expire the tokens monthly in order to maintain the security of the system[16]. Every month the user must exchange all his old tokens for new tokens. It is impossible to extend such a system to allow the coins to have infinite duration.
After reviewing cryptographic literature, we believe that it is too dangerous to implement a system that allows coins to have infinite duration. Although unlikely in the near future, advances in Mathematics and Computer Science could render the current cryptographic methods used in creating digital coins obsolete. What would happen if a bank issued coins of infinite duration, but a few years later advances in technology allowed anyone to mint those coins? The bank would have no choice but to repudiate the currency issued, reducing the value of any digital coins stored to 0. Apart from being a public relations nightmare for the bank, it would create widespread distrust for digital cash systems in general.
Traditional cash is changed every few years as new technologies emerge to fight counterfeiters. The Reserve Bank reduces the circulation of old notes by not reissuing them when they are deposited. Eventually the market penetration of the new notes reaches almost 100%. Even though notes long out of print are still accepted, a merchant would become suspicious if someone used a large number of these notes to pay for goods. Since very few people hoard old notes, it does not hurt the bank to repudiate the notes if counterfeiting is detected.
A similar system could be implemented for old digital coins, but it would be more dangerous than that of the traditional system. Counterfeiting paper notes requires physical resources and expertise. In order to avoid suspicion, a counterfeiter can only use the notes in small amounts, which is time consuming in the physical world. If technology advanced sufficiently, counterfeiting digital coins might be fully automated, and require no more than a powerful computer sitting in the corner minting coins. It is also easy to spend $1 of counterfeited money at hundreds of Internet merchants. Even if they all imposed a limit on how many old digital coins they accept from each consumer, it would not help. Millions of counterfeited coins could be spent before the bank noticed, and stopped accepting the old coins.
We propose a system whereby the coins expire a year after being issued[17]. This allows the bank to update its coins as new technology becomes available, and helps ensure that consumers are not left with useless bits on their hard drive. Besides, storing digital coins on a hard drive for long periods of time is the digital equivalent to hiding money in a shoebox under the bed, and we all know this is not a sound investment strategy.
7 Divisible
In the real world we have notes and coins of different denominations, which can be used to give change. Although change giving can work in the virtual world, it is not an ideal solution. Change giving would incur a greater communications and processing overhead, which could become unnecessarily expensive if a merchant were dealing with hundreds of transactions every minute.
In order for a digital token to be divisible, it should be possible to subdivide it into many tokens of smaller amounts. This allows us to pay the exact price for goods, obviating the need for change giving. Even though traditional cash cannot be divided, divisibility in a digital cash system is used as a more efficient way to achieve change giving.
8 Widely Accepted
A closed system is one in which a unit of value can only be used for specific applications. Telephone cards and photocopy cards are examples of a closed system, because they cannot be used for anything else. Monopoly money is another example of a closed system. Having lots of Monopoly money helps you to win the game, but can be used for little else. In contrast, an open system is one in which a unit of value can be used for many different applications. Credit cards and paper cash are examples of open systems, because they are accepted as payment for a wide range of goods and services.
Setting up a closed system is easy, because it only requires one merchant to accept the unit of value. Flooz [Flooz] and Beenz [Beenz] are examples of closed systems on the Internet, as only a few merchants accept them. Digital cash needs to be widely accepted, i.e. operate in an open system, in order to be truly useful.
9 User-friendly
It should be simple to receive and spend digital cash. Apart from the occasional subtraction to calculate change, not much thought is required to use paper cash. Simplicity leads to mass use, which encourages more merchants to accept payments from the system. As more merchants accept payments, the system becomes more attractive to users, leading to wider acceptability.
10 Unit-of-Value freedom
“If all that digital cash permits is the ability to trade and store dollars, francs, and other governmental units of account, then we have not come very far.” [Matonis, 1995]
As mentioned in section 4.1.4, some form of global currency is needed in order to purchase goods on the Internet, which spans several different countries and currencies.
The ability of individuals and organisations to establish, circulate, and trade their own private currencies is referred to as ‘unit-of-value freedom’. This ‘unit-of-value’ is called a ‘private value unit’ (pvu). There are limited analogous examples of private value units in the physical world, but it is possible for a corporation to mint their own cash [Matonis, 1995].
[Matonis, 1995] discusses the benefits and dangers of monetary freedom, some of which are listed below:
Benefits of monetary freedom
• Robust commerce depends on flexible, responsive monetary systems, which are easily provided by competitive currencies not controlled by governments.
• Competition will exist between private value units, and as in any free market society, this will result in increased innovation and value-added services.
• Citizens living in a country with a weak currency will be able to store their money in a wide array of better performing currencies, which should lead to monetary stability in that country. This is similar to the way in which some countries base their currency on the U.S. dollar to introduce monetary stability.
Dangers of monetary freedom
• Governments will no longer have the ability to manipulate the issuing of currency. This could result in an overheating of the economy, leading to stock market crashes.
• Governments accept a certain amount of responsibility for maintaining the value of the currency that they are issuing. That same responsibility may not be taken on by private companies and organisations, resulting in many people owning worthless cash.
2 Optional Attributes of Digital Cash
The ten attributes given above are enough to give digital cash all the relevant properties of paper cash. Moreover, if we are to create a new form of payment, there is an opportunity to extend the functionality of digital cash beyond that of traditional cash. After examining the literature, we have identified three more attributes that would improve upon true digital cash:
1 Micropayments
In the physical world it is infeasible to charge for anything worth less than a cent. The handling cost for physical coins is too large to make it worthwhile accepting very small payments. The Internet brings new opportunities in this regard. Digital cash payments on the Internet are merely a transfer of bits and need involve no human intervention, thus the cost of receiving payment and banking the revenue is negligible for a merchant. As the cost of performing a transaction decreases, it becomes possible to charge less per transaction.
Micropayments are especially suited to charging for information on the Internet, where the cost of delivering the ‘good’ is also negligible. Micropayments would allow Internet vendors to charge a tenth or hundredth of a cent to view a particular web page.
2 Conditional Repudiation and Recovery
When our wallet is stolen, we lose all the cash in it, with little or no chance of ever getting it back. For true digital cash, if someone were able to steal our digital coins, there would be no way to recover them. Conditional repudiation refers to our ability to go to the bank and report that our e-cash was stolen, and have the stolen coins repudiated by the bank, leaving the thief with useless money. The bank should reimburse any e-cash that has not already been spent, allowing us to recover our
e-cash.
The ability to render useless the money a thief has stolen should greatly reduce theft. Consumers would also feel safer, knowing that even if their smart card with all their cash on it were stolen, it could all be recovered.
3 Scalable
If a digital cash system were to be widely accepted on the Internet, it would need to handle millions of users, each making hundreds of transactions a day. A scalable system allows the bank (or cash issuing institute) to cope with a high volume of traffic withdrawing and depositing digital coins. The system should do so without delays in redeeming coins for value. It should also not require the bank to purchase very expensive hardware just to keep track of serial numbers, in order to prevent double spending. The system should allow multiple banks to issue and redeem digital coins, and not require users to perform all their transactions with one central bank. A scalable system ensures that the number of users does not outgrow the system’s ability to service those users.
3 Review
In this chapter we have described the ten key attributes of true digital cash. A true digital cash system is secure, anonymous, off-line capable, portable, two-way, divisible, widely accepted, user-friendly, and allows for unit-of-value freedom. We have explored digital coins of infinite duration, and decided that it would be too dangerous to implement a digital cash system with this feature. New digital coins are released every year, as new measures are invented to thwart counterfeiters. Not only does this practice protect the bank and the consumers, but also models the way a Reserve Bank issues traditional cash. These ten attributes parallel the important attributes of traditional cash. Three optional attributes have been proposed that would increase the functionality of digital cash. These are the ability to make micropayments, conditional repudiation and recovery of digital coins, and a scalable system.
Achieving Digital Cash
“True digital cash as an enabling mechanism for electronic commerce depends upon the marriage of economics and cryptography.”
- Jon W. Matonis
In Chapter 4 we discussed the attributes of an ideal digital cash system. In this chapter we draw on Chapters 2 and 3 to discuss ways in which we can create an ideal digital cash system. We start with a basic system, and gradually develop a system to satisfy most of the attributes. There are sometimes many ways of implementing a system so that it has a certain property. Where we are unable to extend our basic system, or where it is relevant, we mention an alternate method that satisfies our objectives.
1 Tamper Resistant Smart Cards
As chips have been called upon to store ever more valuable information, people have sought to protect the integrity and confidentiality of the bits on a chip. The techniques of cryptography introduced in Chapter 2 provide the means for authorisation, integrity and confidentiality, so the essential resource that needs to be protected on a chip is the key. This goal is made more difficult when the chip is on a smart card and can be taken home, because a devious user has all the time in the world to try to gain access to the chip. In order to prevent unauthorised access to the chip, tamper resistant smart cards have been developed. These smart cards have various protection mechanisms manufactured into the chip (such as erasing all the information stored if tampering is detected) to ensure that access can only be gained by using the approved smart card readers, available to merchants and banks.
Surely, then, all we need to implement a digital cash system is some smart card readers, and tamper resistant smart cards with a counter on them? Value can be added to the card by increasing the counter, and spent by decreasing the counter. This may seem like a viable solution, but [Brands, 1994] warns us not to place too much trust in the security of tamper resistant devices. [Anderson et al, 1996] goes further, to demonstrate techniques that were used to defeat the tamper resistance of all commercial smart cards available in 1996. Thus, our ‘secure’ digital cash system using counters on tamper resistant smart cards, can be reduced to a system that allows anyone with the right expertise to mint their own money[18].
So should we just ignore tamper resistant smart cards? [Brands, 1994] proposes that we use them as the first line of defence only, and that if the tamper resistance were broken, the underlying system should prevent widespread, undetectable minting of money.
2 Developing a Digital Cash System
Since we are unable to rely on tamper resistant smart cards to maintain the security and integrity of a digital cash system, we need to devise our system under more stringent constraints. We assume that the consumer and the merchant are able to read and modify any digital token received from the bank. We also assume that the consumer and merchant trust the bank to redeem the coins for value, and that the consumer trusts the merchant to deliver goods that are paid for[19], but for all other purposes the bank, merchant, and consumer do not trust each other. Furthermore, our system must protect the bank from collusion between the merchant and consumer, and the consumer from collusion between the bank and the merchant. For the purpose of this explanation, Alice plays the part of the consumer, and Carol the part of the merchant.
1 Secure
In order to ensure that only the bank can mint digital coins, the bank must create a public/private key pair, and get a certification authority to certify its public key. We prepare the digital coins as follows:
1. The value of the coin[20], a unique serial number of around 160 bits, the name of the bank, the currency of the coin, and possibly the Internet address where the coin can be redeemed for value, are all bundled up into a message.
2. The bank hashes the messages and signs the hash value.
3. The bank bundles the message, and the signed hash value together to form the digital coin.
Since only the bank is capable of signing with its private key, we have ensured that only the bank is able to mint valid digital coins. It is easy to check whether a digital coin is valid, by checking the bank’s signature on the hash value, and hashing the message to ensure that we obtain the same hash value.
Since the bank sends us valid digital coins over an open network (the Internet), we need to worry about someone intercepting the coins, and stealing our money. To prevent this, we set up a secure channel with the bank. This can be done using the methods described in Chapter 2. [Schneier, 1996] discusses various ways to provide mutual authentication[21] (the bank knows that it is talking to Alice (and not someone else), and Alice knows that she is talking to the bank).
For our purposes we will assume a secure, mutually authenticated line of communication between Alice and the bank, and between Carol and the bank. We also assume that Alice has authenticated Carol, and has a secure connection with Carol, before handing over her digital coins. Carol has no need to authenticate Alice, since Carol is willing to accept valid digital coins from anyone[22].
The procedure for Alice to withdraw a digital coin is as follows:
Withdrawal Protocol #1
1. Alice requests a digital coin from the bank, for a certain amount.
2. The bank checks that Alice has funds in her account, and debits her account.
3. The bank prepares a digital coin, and sends it to Alice.
Once Alice has the digital coin, it is her responsibility to keep it safe. If her hard drive crashes, or someone runs off with her computer, Alice would have lost her money. This is as the same as losing a paper note – once it’s gone, it’s gone.
The procedure for Alice to spend a digital coin at Carol’s store is as follows:
Spending Protocol #1
1. Alice and Carol agree on the goods, and the price of the goods[23].
2. Alice sends Carol her digital coin. (Assume for the moment that it has the exact value of the goods).
3. Carol verifies the bank’s signature on the coin, and contacts the bank, to ensure that the coin has not been spent before.
4. The bank verifies its signature, and checks the serial number of the coin. If it has not been spent, the bank inserts the serial number into its database of spent coins, and credits Carol’s account. If the coin has been spent, the bank refuses to credit Carol’s account and notifies her. In this case, Carol does not give the goods to Alice.
5. Carol gives the goods to Alice.
Double spending is prevented, because the bank checks to see whether a particular coin has been spent already, before crediting a merchant’s account. There is no way for the bank to tell who tried to double spend the coin, whether it was Alice or Carol. This system provides no anonymity for Alice, since the bank can link the serial number of her coins with the merchant she spent them at. By colluding with the merchant, the bank can even obtain a list of the actual goods that Alice bought. Since the bank ensures that each note has a unique serial number, there is no chance of two valid notes having the same serial number [Froomkin, 1996].
The system described above is a secure, on-line system. It requires the merchant to maintain a constant connection with the bank, verifying each coin, in order to prevent double spending. Coins are not allowed to circulate freely, and must flow up the hierarchy, from consumers to merchants to banks. Even though it cannot detect who tried to double spend a coin, the system prevents double spending altogether, and thus the incentive to try to double spend. Since the bank is unable to detect who is double spending, it is impossible for the bank to frame Alice, by fraudulently claiming that she double spent a coin.
2 Anonymous
If Alice is to buy something from Carol with digital coins, and remain anonymous, we need a more complex protocol. Recall the concept of a blind signature from Chapter 3. If Alice could get the bank to sign her money order without the bank knowing its serial number, the bank would have no way of tracking her spending habits. Obviously the bank would not just sign any money order Alice gives it, because Alice may ask for $10, and then get the bank to sign a money order worth $1000. To solve this problem we use a technique called cut and choose [Schneier, 1996].
Cut and choose is similar to how we divided something when we were children. If two people want to share a cake, one person would cut the cake, and then the other person would get to choose the first piece. The person cutting the cake is inspired to cut fairly, since the other person gets to choose their piece first, and is most likely going to choose the bigger piece.
In order to get the bank to sign a blinded money order, Alice needs to convince the bank that she is not trying to cheat. This is how Alice would get a $10 blinded coin [Wayner, 1996]:
Withdrawal Protocol #2
1. Alice prepares 100 blinded money orders by randomly choosing[24] a serial number for each one[25], filling in an amount of $10, and the correct bank name and currency (Alice gets to cut). She then gives all 100 blinded money orders to the bank.
2. The bank randomly chooses 99 money orders, and asks for them to be unblinded (The bank gets to choose).
3. Alice sends the bank the blinding factor for the 99 money orders.
4. The bank unblinds the money orders, and checks that they contain the correct information (amount, currency, name of bank, etc.). If all the information is correct, the bank is convinced that the final blinded money order is also correct. Since the bank randomly chose the 99 money orders, Alice only has a 1 in 100 chance of getting the bank to sign a bogus money order. The bank could make the penalty for trying to cheat severe enough, so that it is not worth the risk.
5. The bank signs the one remaining blinded money order, debits Alice’s account, and sends the digital coin to Alice[26].
6. Alice unblinds the signed money order, and now has a $10 digital coin with a serial number that is unknown to the bank.
The procedure that Alice uses to spend the digital coin is identical to that in section 5.2.1. Even though the bank is able to check the serial number of the coin when it is spent to ensure that it is not double spent, the bank is unable to link the coin to Alice’s withdrawal of the coin, because it never saw the actual serial number.
This is similar to Ecash, the digital cash system from DigiCash, in that it is an on-line system that provides payer anonymity. Carol has no anonymity, since the bank requires her to deposit any coins she receives directly into her account. Thus, the bank is able to record all amounts of cash that Carol receives [Grabbe, 1998d]. The current system can easily be extended to allow for payee (Carol) anonymity.
We introduce a new protocol, called the coin exchange protocol. This protocol, inspired by the PayMe system [Peirce et al, 1995], allows old coins to be exchanged for new coins. This is done anonymously, so Carol no longer authenticates herself to the bank in order to perform the coin exchange protocol. This allows Carol to exchange coins she receives from Alice for new coins from the bank anonymously, provided the coins from Alice have not been double spent. This is the new procedure Alice and Carol perform when Alice spends her digital coins:
Spending Protocol #2
1. Alice and Carol agree on the goods, and the price of the goods.
2. Alice sends Carol her digital coin. (Assume for the moment, that it has the exact value of the goods).
3. Carol verifies the bank’s signature on the coin, and contacts the bank, to ensure that the coin has not been spent before.
4. Carol also prepares 100 blinded coins for the same value as Alice’s coin, and the bank uses the same cut and choose protocol to issue a new anonymous coin to Carol, in exchange for Alice’s coin.
5. Carol gives the goods to Alice.
The bank is no longer able to track deposits into Carol’s account, since Carol can anonymously exchange Alice’s coins for new anonymous coins.
Even though the bank has no idea what Alice does with her money, it is still able to track how much money she is withdrawing from her account. Systems have been proposed which allow Alice to open a completely anonymous account with the bank, but at the same time have her details revealed, should she try to double spend any coins. Such a system is beyond the scope of this project.
The current system is a secure, completely anonymous system, which relies on an on-line connection in order to prevent double spending. Once again the bank cannot determine who double spent, so is unable to frame Alice by fraudulently claiming that she double spent a coin.
3 Off-line capable
The previous systems discussed are not suitable for off-line transactions, because double spending is prevented by verifying every digital coin as it is received. For a system to be off-line capable, it must allow a merchant to bank once or twice a day, leaving no way to prevent Alice from double spending a coin. Recall that a tamper resistant smart card may prevent the average user from double spending, but it won’t prevent expert users and well funded criminal organisations from double spending.
[Brands, 1994] proposes a system which uses a tamper resistant smart card as its first line of defence, and if this is bypassed, the system limits the amount of illegal money that can be spent. Another system allows double spenders to be detected after the fact, which is the approach we use [Schneier, 1996]. By detecting and prosecuting double spenders for fraud, it is hoped that the occurrence of double spending will be reduced [Froomkin, 1996].
In order to detect double spenders, the identity of the consumer is encoded in the coin in such a way that spending a coin once does not reveal their identity, but spending it twice does. This is how the identity is encoded into the digital coin [Schneier, 1996]:
Withdrawal Protocol # 3
1. Alice prepares 100 money orders, all for the same amount, with each coin having its own unique serial number, and some other information. Together with each money order, Alice bundles 10 pairs of identity strings,
I1, I2,…, I10.
Each of these pairs is generated as follows:
Alice creates a string with her name, address, and other identifying information the bank wants, and uses the secret splitting protocol in section 2.8 to split each string into two pieces, a left and a right half. Alice then commits to each piece using the bit commitment protocol in section 2.7. Thus the money order contains identity strings that look like:
I1 = (I1L,I1R)
I2 = (I2L,I2R)
…
I10 = (I10L,I10R)
Each I1L, I1R, I2L,…, I10R is bit committed with a different key.
Alice’s identity is fully encoded in each Ii (i = 1..10). E.g. if someone obtains I2L and I2R they can reveal Alice’s identity. If, however, someone has I2L and I3R they have no information about Alice’s identity[27].
2. Alice blinds the 100 money orders, and sends them to the bank.
3. The bank randomly chooses 99 money orders, and asks Alice to unblind them, and reveal all the identity strings therein. Since Alice bit committed the identity strings, there is no chance for her to cheat by encoding someone else’s identity in the identity strings, and making the bank think that Alice’s identity is encoded instead.
4. Alice sends the bank the blinding factor, and the keys she used to bit commit each half of every identity string, for the 99 money orders.
5. By the cut and choose protocol, the bank is sure that the remaining blinded money order is for the correct amount, and that Alice’s identity is correctly encoded therein. The bank signs the blinded money order, and sends it to Alice.
6. Alice unblinds the money order, and obtains her digital coin.
The digital coin Alice gets back from the bank has ten instances of her identity encoded somewhere inside, with each instance as a split secret. Since Alice bit committed each half of her identity, only she can open them, but upon opening them it is easy to verify that they were opened correctly. This can be done by including the name of the bank (a fixed bit-string) inside each piece that Alice bit commits. This string can then be checked when the bit committed piece is opened. It is impossible for Alice to change the coin in any way (E.g. by trying to encode someone else’s name into the coin), because then the bank’s signature will no longer be valid.
To ensure that Alice’s identity is revealed, should she try to double spend her digital coin, we also need a more complex spending protocol. This is how it works [Schneier, 1996]:
Spending Protocol #3
1. Alice and Carol agree on the goods, and the price of the goods.
2. Alice sends Carol her digital coin.
3. Carol verifies the bank’s signature on the coin, and produces a random 10-bit challenge string b1,b2,…,b10. Carol sends this 10-bit challenge string to Alice.
4. Depending on the value of bi (0 or 1), Alice sends Carol the key to open either the left or right half of Ii (i = 1..10).
5. Carol opens either the left or right half of each Ii, and checks whether it has opened correctly (i = 1..10). She then stores the opened Ii’s along with the digital coin.
6. Carol gives Alice the goods.
7. Carol contacts the bank at the end of the day, and sends the bank her digital coins, along with all the identity information for each coin. An exchange protocol similar to that in section 5.2.2 can be used to give Carol anonymity.
In the spending protocol above, Carol does not contact the bank before giving the goods to Alice. Instead she contacts the bank at some later time, making it off-line. Alice only ever reveals half of her identity to Carol, and at no time does she reveal both parts of any Ii to Carol. With only one half of any Ii it is impossible to tell Alice’s identity. But, if Alice tried to spend the coin again, she would receive another 10-bit challenge string from the merchant. Since this 10-bit challenge string is random, there is only a 1 in 210 chance of both merchants selecting the same random 10-bit challenge string[28]. When the merchants deposit the coin in the bank, the bank is able to take the identity information that was opened by each merchant, and combine them, such that at least one Ii reveals Alice’s identity (Remember, having just IiL and IiR for any i, is enough to reveal Alice’s identity) [Schneier, 1996].
If Carol tries to deposit Alice’s coin twice, the bank would detect that Carol is trying to cheat. Since only Alice can open any halves of her identity, Carol has to submit the same identity information along with the coin. Invalid identity information would immediately alert the bank to Carol’s attempted deception. There is only a 1 in 210 chance of two merchants selecting the same random challenge string used to get Alice to open her identity. Thus, the bank is fairly certain that it is Carol, and not Alice trying to cheat. If Carol is using the coin exchange protocol to protect her identity, there is no way the bank can trace the cheating to her, but the bank knows that it is a merchant, and not Alice who is trying to cheat, and it will not exchange the duplicate coin for a new one. [Schneier, 1996].
It is impossible for Carol to try to frame Alice by double spending the coin, because only Alice can open the halves of her bit committed identity strings. It is also impossible for Alice to frame Carol, since the next merchant she tries to double spend her coin at gives her another random 10-bit challenge string, which is highly likely to be different from Carol’s. It is possible for the bank to create a digital coin with Alice’s identity encoded inside, double spend the coin, and claim that Alice is trying to defraud the bank by double spending. This can be avoided if Alice signs the identity string before bit committing it. That way, only Alice is capable of inserting her identity into a digital coin.
If Carol wants to ensure that the coins she receives have not been double spent (E.g. for a large purchase), she is able to contact the bank and deposit the coin before giving the goods to Alice. The system can be scaled back to an on-line system, where detecting double spenders after the fact is not sufficient (There may be delays in prosecuting the double spender and reclaiming the money, which, for large purchases, may be unacceptable to a merchant). This is not unlike present credit-card schemes, which verify large transactions on-line.
Storing Alice’s identity 10 times in each coin makes the coins much larger, resulting in more communications and storage overhead. The digital cash system developed by Stefan Brands uses Schnorr authentication [Grabbe, 1998b], making each coin much smaller. Recall from Geometry, that any two points in a plane are enough to uniquely determine a line in that plane. In Brands’ scheme, the identity is encoded as a line (or perhaps the slope of the line) in a plane. Every time a coin is spent, a different point on the line is revealed. Spending the coin once reveals no information, but spending it twice reveals the line, and hence the consumer’s identity [Grabbe, 1998b].
The system above is a secure, anonymous system, which does not require on-line clearance of digital coins. Double spenders are revealed after the fact, allowing the bank to press charges of fraud.
4 Portable
Technically, all that is required to make our current system portable is to move digital coins from a computer onto a floppy disk, or other removable media. Since digital coins are simply bit strings that need no protection, they are inherently portable, like any other data. This allows us to carry our digital coins around in our pocket. Unfortunately, this is not sufficient to make the system portable. The infrastructure in the physical world to accept digital coins is not in place. Such infrastructure is not likely to be put in place unless there is an economic incentive to do so, which is largely independent of the technical details of a digital cash system.
A widely accepted, user-friendly digital cash system would create an economic incentive for brick-and-mortar merchants to accept digital coins. The cost for a virtual merchant to accept digital coins is not much more than purchasing the software to handle the digital coins, making the barrier to entry in this market much lower than in the physical world. Coupled with the lack of payment options available on the Internet, it seems more likely that the widespread use of digital cash on the Internet will drive its acceptance in the physical world, than for it to happen the other way around.
But a notable counter-example already exists. Mondex, a smart card based electronic money system with limited anonymity, has already launched successful pilots in many European cities. Mondex is backed by MasterCard, one of the two largest credit card clearing organisations in the world [Froomkin, 1996]. Mondex supports face-to-face and electronic transfer of value, and widespread acceptance of Mondex in the physical world could enable it to become the preferred payment method on the Internet.
The issue of currency dependence is subject to political and economic circumstances. Our digital cash system allows digital tokens to be created in any currency. The usefulness of this currency for purchasing goods at local brick-and-mortar stores is beyond the technical specification of the system. We briefly discuss the possibility of global currencies in section 5.2.10.
5 Two-way
The difficulty with enabling peer-to-peer payments is that digital coins are essentially bearer tokens, because the consumer’s name is encoded somewhere in the coin [Grabbe, 1998b]. The coin exchange protocol in section 5.2.2 allows peer-to-peer payments without the need to register as a merchant, but requires consumers to contact the bank when they transfer value between one another. It does this by allowing Alice to anonymously redeem Bob’s digital coins (with Bob’s name encoded therein), and receive her own digital coins (with Alice’s name encoded therein) from the bank.
Digital coins that allow for off-line peer-to-peer payments must necessarily grow in size. This is because they need to accumulate bits every time they are transferred, in order to prevent double spending [Grabbe, 1998b].
In order to reduce the affect of transferable digital coins on the money supply, we could implement limited transferability. This would allow for a limited number of peer-to-peer payments before a coin must be deposited (or exchanged for a new coin). Making the coins expire after a certain time would achieve the same objective, but it would then not allow for coins of infinite duration. Unfortunately, both of these approaches still leave room for criminals to use the peer-to-peer payment attribute of a digital cash system to launder money. Mondex tries to solve the issue of money laundering by only allowing ₤500 to be stored on the card at any time. Money launderers would then require suitcases full of Mondex cards, which might be even more difficult to manage than suitcases full of paper cash. Limiting the maximum value of a digital coin would have no effect on money laundering on the Internet, since it is just as easy to deposit $10 000 once, as it is to make 10 000 deposits for $1 (or whatever the maximum coin size is) [Bortner, 1996].
6 Infinite duration
Our system already allows the digital coins to have infinite duration, but as we argued in section 4.1.6, it is dangerous for infinite duration coins to be issued. Attaching an expiry date to the coin involves a slight change in both the withdrawal and spending protocol. When Alice withdraws a digital coin, she is required to attach an expiry date to the money order, which upon unblinding, the bank checks along with the other information in the money order. When Alice spends a coin, Carol needs to check the expiry date on the coin before accepting it, to ensure it is still valid.
7 Divisible
Change giving would be unnecessary for non-anonymous coins. When the goods are purchased, Alice would pay with the next largest denomination coin, and attach the value used in the spent coin. Alice then signs the coin. When the bank receives the coin, they credit the unspent portion of the coin back to Alice. This is far from ideal, since it cannot be implemented in an anonymous system.
It is possible for Alice to carry coins of all different denominations, and use many coins of different denominations to pay the exact price. This solution creates space and communications overhead, just as keeping an array of 5c, 10c, 50c, etc. coins in our wallet does in the physical world. As in the physical world, it is easier to carry a $20 note, and receive change from the merchant. Such a system could be implemented if Carol gave Alice change in digital coins, which Alice then exchanged for new coins from the bank before ‘leaving’ Carol’s store. This is not ideal, since it requires Alice to contact the bank every time she receives change from a merchant.
A form of ‘digital clearing house’ could be used to break a digital coin down into smaller denomination coins. Alice would then contact the clearing house and receive exact change before purchasing goods from Carol. Even though this still requires Alice to make a connection to the clearing house with almost every purchase, it is preferable to change giving, since Alice is no longer required to trust Carol. The clearing house could be the bank, which is trusted anyway to redeem the coins.
Both of these systems must be performed on-line, however. [Grabbe, 1998b] laments that no off-line, perfectly unlinkable, and efficient cash-divisibility scheme is possible[29].
It is already possible for Alice to create money orders for different amounts, and thus to store coins of different amounts in her digital wallet[30]. We extend our system to provide a mechanism similar to the coin exchange protocol, whereby Alice can contact a digital clearing house, and break her coins down into coins of smaller value. This is done by exchanging a digital coin for many coins of smaller value[31]. Together, they allow Alice to perform a limited number of purchases off-line before she needs to contact a clearing house to make change. This is not a great restriction, since Alice needs to contact the bank periodically in order to obtain more digital coins anyway. Every time Alice contacts the bank she can ensure that she has the desired proportion of each coin denomination.
In order to reduce the number of times Alice needs to contact the digital clearing house we force all digital coin denominations to be powers of 2. Such a system requires less change giving than a metric system.
8 Widely Accepted
[Matonis, 1995] notes that the wide acceptance of digital cash is primarily a brand issue, in which digital cash systems supported by recognised brands would gain trust and acceptance in a large commercial zone. Provided the system is technically secure (a broken system would most likely not gain widespread acceptance), marketing, ease of use and availability will largely determine a system’s acceptance. The failure of one digital cash system will make consumers wary of all systems, something even a perfect system cannot protect itself against.
9 User-friendly
User-friendliness is determined by the user interface provided with the system. We should not be required to remember user names or long pass phrases. If spending is made as simple as merely keying in the amount to spend, the overall security of the system is reduced, since anyone who gains access to our computer can spend our digital cash. By requiring pass phrases we increase the security, but reduce the ease of use.
We propose a system that stores the digital coins on a smart card equipped with a finger print reader. We allow the user to choose whether to use a pass phrase or not, leaving the level of security up to the user[32]. The cash is not lost in a hard drive crash, and can not be erased by mistake. People feel more comfortable with money if it is represented by something physical, and are able to ensure the security of the smart card themselves. Digital coins that are left on a computer can be lost or stolen in any number of ways, but so long as users have control over the smart card, they will determine what happens to the cash (to a large degree).
10 Unit-of-Value freedom
Any digital cash system is essentially currency independent. We could mint our own digital coins, in our own currency if we wish. In order to achieve true unit-of-value freedom though, the unit-of-value chosen needs to be widely accepted, and backed by an appropriate form of value. To ensure that consumers are able to redeem their digital coins for value, the coins need to be backed by some form of value, just as paper cash is sometimes backed by gold, or silver. Digital coins can be backed by paper cash, securities, gold, or any other form of value. [Matonis, 1995] proposes that companies such as Microsoft, IBM, and Coca-Cola have an advantage if they issue a private form of currency (E.g. Microsoft Bills), since their brands are recognised world-wide.
11 Micropayments
The cost of transmitting, storing and processing bits is extremely low, but not free. In order to be suitable for micropayments, the cost of transferring and redeeming a digital token must be less than the value of the payment being made. Since bandwidth, storage space, and processing power are becoming cheaper all the time, it is possible that any reasonable digital cash system could be used for micropayments in the near future.
The system we have developed so far does not support micropayments very well, because it has a fairly large storage, processing, and communications overhead. An example of a system suitable for micropayments, is PayWord [Rivest et al, 1998]. This system makes extensive use of hash functions, which are much quicker to compute than digital signatures. The consumer ‘commits’ to pay the merchant a certain amount, which is opened gradually as the consumer unlocks the commitment, piece by piece, allowing the merchant to redeem it for value. Only unlocked sections of the commitment can be redeemed by the merchant. Unlocking sections of a commitment, and verifying that it is correctly unlocked, only require computing and transferring hash functions, greatly reducing communication and processing overhead.
12 Conditional Repudiation and Recovery
Storing backups of digital coins is not a good idea, since it would provide another opportunity for a thief to steal them. The system developed so far relies on secret keys to unlock bit committed pieces of the identity string, and any coins stolen are useless without these keys, since the merchant will not accept the coin unless parts of the identity string are unlocked.
A better alternative is to backup the signed blinded digital coin from the bank, along with the blinding factor. If digital coins were stolen from Alice’s computer, she would contact the bank, and provide the bank with its signed blinded digital coins along with the blinding factor. This allows the bank to verify that it did issue the coins to Alice, and unblind the coins to retrieve their serial numbers. If they are not already spent, these serial numbers can be placed into the bank’s database of spent coins. The bank then refunds Alice for any coins that were not already spent. Since the keys are not stored with the backup of the digital coin, if a thief stole the backup he would not be able to spend the coins.
The above repudiation and recovery works perfectly in an on-line system, since double spending of the coin is prevented. Unfortunately, in an off-line system there is nothing to prevent Alice from spending her coins, and then contacting the bank to claim that they were stolen.
If only small purchases are allowed to be off-line (E.g. less than $100), then the bank can offer conditional repudiation and recovery to Alice for any coins worth over $100, since they need to be cleared on-line.
13 Scalable
[Grabbe, 1998b] uses the example of a single central server which keeps track of all the coins spent in order to prevent double spending. The server would limit the scalability of the system, because as more coins are spent, the size of the database increases, increasing the cost per transaction of detecting double spending. Systems such as NetCash and PayMe [Peirce et al, 1995] are designed specifically for scalability.
Rather than keeping a database of all spent coins, the PayMe system stores the serial numbers of all issued coins, deleting coins from the database as they are spent. Coins are only considered valid while they are in the database. Such a database would not grow indefinitely large, but is only as large as the number of issued coins. Our system cannot be extended to incorporate this, because the anonymity of the system relies on the bank not knowing the serial number of the issued coin.
Instead, we propose an extension to our system which relies on the coins expiring after a year. When Alice withdraws a digital coin from the bank, she creates a serial number by choosing a random 160 bit number, and concatenating the year of expiry. Thus, the bank no longer needs to store expired coins in its database. By searching the database for coins that expired the year before, and deleting them (or moving them elsewhere[33]), the bank can speed up database searches, and reduce the cost of detecting double spending. Our extension limits the size of the bank’s database to coins that do not expire in the current year.
3 Review
Tamper resistant smart cards are not secure enough to guarantee the security and integrity of the bits stored on their chips. Thus, it is foolish to trust the security of a digital cash system to the tamper resistance of a smart card alone. To this end protocols have been developed which allow for a secure, anonymous, off-line digital cash system to be implemented. Some of these protocols have been discussed in this Chapter, and a system has been developed which satisfies all three of those attributes. Peer-to-peer payments and divisibility proved to be more difficult attributes to implement. On-line protocols have been proposed which satisfy these attributes, but we were unable to find an off-line protocol to satisfy these attributes. Portability, wide acceptance, and unit-of-value freedom are largely independent of the technical specifications of the digital cash system, and depend more on political and economic circumstances.
The ability to support micropayments depends on the system’s storage, processing and communication overheads. For a digital cash system, provided the cost of those overheads is less than the value of the payment, it is viable to support micropayments. Conditional repudiation and recovery are easily supported in an on-line system, where double spending is prevented. PayMe is a scalable system that stores the serial numbers of issued coins only. We are unable to extend our system in this manner, so we use the fact that our coins expire a year after being issued to limit the size of the database used to detect double spending.
iKP and SET – NOT Digital Cash
“The security issue – knowing who is communicating with you will be crucial to realizing the commercial promise of the Internet.”
- Bill Gates
Credit cards are the most widely used payment mechanism on the Internet today. Payment by credit card involves sending one’s credit card number to the merchant, and the merchant billing that credit card. This has resulted in widespread fraud, since unscrupulous merchants sometimes charge more to the credit card than agreed. The Internet is an open network, thus there is also an opportunity for an eavesdropper to listen in on one’s communication with the merchant, and obtain a credit card number, allowing them to make charges on that credit card. Encrypting the credit card information sent to the merchant has solved some of these problems, but cannot prevent a merchant from overcharging, or from using our credit card information elsewhere.
1 What is iKP?
In an effort to facilitate secure credit card transactions on the Internet, IBM developed iKP (Internet Keyed Payments), a family of on-line payment protocols. Public-key cryptography is used to provide security, and to establish a non-deniable audit trail through the use of digital signatures [Wayner, 1996]. iKP consists of three separate protocols (1KP, 2KP, and 3KP), each requiring progressively more established public key infrastructures.
The three parties involved in a transaction are the consumer, merchant, and acquirer (a bank or credit card authorisation authority such as VISA). 1KP requires only the acquirer to possess a public/private key pair. 2KP also requires the merchant to possess a public/private key pair, and 3KP requires the acquirer, merchant, and consumer to possess key pairs [Grabbe, 1998c]. iKP makes use of a certificate authority (CA) to authenticate the public keys of consumers, merchants, and acquirers. The three different protocols were developed to encourage their easy adoption, and for more security to be added as the public key infrastructure improved.
iKP protects payments from an eavesdropper (who listens to messages to get credit card numbers), an active attacker (who sends forged messages), or an insider (such as a dishonest merchant overcharging, or charging twice) [Grabbe, 1998c]. Sending encrypted credit card details only protects against an eavesdropper, and offers no further security.
1 iKP Security Levels
1KP, 2KP, and 3KP provide different levels of security. Table 6-1 [Grabbe, 1998c] with additions from [Wayner, 1996] lists the various security requirements that 1KP, 2KP and 3KP satisfy. 1KP provides basic security for the acquirer, merchant, and consumer, in that the consumer’s credit card number is protected from an eavesdropper through the use of encryption. Since the consumer is anonymous to the merchant, the merchant is unable to record the consumer’s credit card number [Wayner, 1996]. This prevents merchants from storing a list of their consumers’ credit card details. Such lists have proved to be an attractive target for hackers.
2KP adds proof for both the acquirer and consumer that the merchant has authorised the transaction. Such authorisation could be produced in court, should the merchant fail to deliver the goods.
|Required by |Requirement |1KP |2KP |3KP |
|Acquirer |Reduced fraud, through protection of credit card |✓ |✓ |✓ |
| |numbers from eavesdroppers and corrupt merchants. | | | |
| |Proof that the merchant has authorised the | |✓ |✓ |
| |transaction. | | | |
| |Proof that the consumer has authorised the | | |✓ |
| |transaction. | | | |
|Merchant |Proof that the acquirer has authorised the |✓ |✓ |✓ |
| |transaction. | | | |
| |Provable accreditation from the acquirer[34]. | |✓ |✓ |
| |Proof that the consumer has authorised the | | |✓ |
| |transaction. | | | |
|Consumer |Protection of credit card number from eavesdroppers|✓ |✓ |✓ |
| |and corrupt merchants. | | | |
| |Proof that the acquirer has authorised the |✓ |✓ |✓ |
| |transaction. | | | |
| |Anonymity from the merchant. |✓ |✓ |✓ |
| |Proof of merchant accreditation. | |✓ |✓ |
| |Receipt from merchant for goods. | |✓ |✓ |
| |Impossibility of unauthorised transactions. | | |✓ |
Table 6-1: iKP Security Levels
Currently, Internet merchants cannot produce signed transaction slips from their consumers, thus they have no way of proving that a consumer authorised a purchase. Credit card companies, such as VISA and MasterCard, have increased the credit card charges for Internet merchants, owing to the high rate of consumer repudiation on Internet purchases. 3KP solves this problem by providing the acquirer and merchant undeniable proof, by way of a digital signature, that the consumer authorised the transaction. A thief would then require knowledge of a consumer’s credit card number, and access to the corresponding private key, in order to conduct a fraudulent transaction.
2 1KP Protocol
The 1KP protocol is as follows, with Alice playing the part of the consumer, and Carol that of the merchant [Wayner, 1996]:
1. Alice chooses an item from Carol’s store. Carol sends an offer to Alice (an invoice), containing the cost, currency of the transaction, date, and Carol’s ID number. Carol sends the public key and certificate of the acquirer processing the transaction to Alice as well.
2. Alice checks the certificate of the acquirer. If it is authentic[35] she bundles her credit card details together with a hash of the invoice, to form a payment[36]. Alice encrypts the payment with the acquirer’s public key, and sends it to Carol. Since Alice’s credit card details are encrypted with the acquirer’s public key, Carol cannot read them.
3. Carol bundles a hash of her version of the invoice, together with the encrypted payment from Alice, and sends this to the acquirer.
4. The acquirer decrypts the payment, and ensures that Alice’s hash of the invoice matches Carol’s hash of the invoice. This ensures that Alice and Carol agree on the details of the transaction. The acquirer then charges Alice’s account, and bundles the approval (or rejection) of the transaction together with a hash of the invoice, signs it, and sends it to Carol.
5. Carol checks the signature of the acquirer, to ensure that the transaction is approved. If so, Carol gives the goods to Alice. Alice can also request to see the acquirer’s authorisation, which Carol can show her.
Figure 6-1 [Wayner, 1996] illustrates the 1KP protocol. Notice that only the acquirer can sign anything, since only the acquirer has a key-pair in 1KP.
Figure 6-1: 1KP Protocol
3 2KP Protocol
The 2KP protocol forces Carol to offer a greater level of accountability. Carol is required to sign the details passed on to the acquirer in step 3, giving the acquirer proof that Carol authorised the transaction. Carol can also send her certificate to Alice in step 1, providing Alice with proof of her accreditation. By signing the acquirer’s transaction authorisation, and sending this to Alice, Carol can give Alice a receipt for the goods. Figure 6-2 [Wayner, 1996] illustrates the 2KP protocol.
Figure 6-2: 2KP Protocol
4 3KP Protocol
In 1KP and 2KP, Carol and the acquirer have no proof that Alice authorised a payment, should it be disputed in court. It is still possible for a thief to spend on Alice’s credit card, since he only needs to know Alice’s credit card number to do this. 3KP provides proof that Alice authorised a payment, to both Carol and the acquirer, and makes it impossible for anyone besides Alice to authorise a payment on her credit card. This is done by Alice signing the payment encrypted with the acquirer’s public key, in step 2. Figure 6-3 [Wayner, 1996] illustrates the 3KP protocol.
Figure 6-3: 3KP Protocol
2 What is SET?
Secure Electronic Transaction (SET) is a technical standard derived from iKP. It was developed by MasterCard and VISA as a way of making secure credit card purchases over an open network, such as the Internet [Grabbe, 1998c]. Unlike iKP, which is a theoretical set of protocols, SET was designed to be implemented on the Internet. To this end, MasterCard and VISA have released a programmer’s handbook for SET, to encourage e-commerce solutions to be developed using SET as the payment mechanism [Wayner, 1996]. Unfortunately, the SET standard has become unwieldy, and difficult to implement – the programmer’s handbook, which is more than 400 pages long, attests to this.
Although the standard allows the processing of payments where the consumer does not have a public/private key pair, SET is designed for transactions where the acquirer, merchant, and consumer all have public/private key pairs. SET makes extensive use of certification authorities to vouch for the authenticity of a person’s public key [Wayner, 1996]. SET is similar to 3KP above, so we do not discuss it here. Refer to [Wayner, 1996] for a more in depth discussion of SET.
1 Benefits of SET
SET addresses the following business requirements [Grabbe, 1998c]. It:
• Provides confidentiality of payment information (from merchants and eavesdroppers).
• Ensures the integrity of transmitted data.
• Authenticates the card holder as a legitimate card account user.
• Authenticates that the merchant is allowed to accept credit card payments.
• Gives security from eavesdroppers to the acquirer, merchant, and consumer.
• Is not dependent on transport security mechanisms (such as SSL).
• Is platform and network independent.
3 What About Digital Cash?
iKP and SET are not digital cash. They rely on the existing credit card infrastructure to support payments on the Internet, and are merely secure credit card transmission mechanisms. In these two systems, there are no digital tokens which represent value, and both the transaction and authorisation must be done on-line. The signed payment from the consumer is an authorisation to charge a certain amount to his credit card. iKP and SET are not anonymous, but instead provide each transaction with a secure audit trail.
4 Review
iKP is a family of protocols developed by IBM to allow for secure credit card transactions on the Internet. 1KP, 2KP, and 3KP are the three separate protocols in the iKP family, each offering a greater level of security, and non-repudiation, but requiring a more established public key infrastructure. SET is a technical standard, derived from iKP, that was developed by MasterCard and VISA to allow for secure credit card transactions on an open network, such as the Internet. iKP and SET are not digital cash, but instead rely on the existing credit card infrastructure to transfer value.
Recommendations for Rhodes Campus
“Vision without action is a daydream. Action without vision is a nightmare.”
- Japanese Proverb
Two other South African universities have implemented an electronic payment systems to create ‘cashless campuses’. They are using it to market their universities, by claiming that a cashless campus will reduce the incidence of crime. Crime levels are high in South Africa, and such a claim gives them a significant competitive edge over other tertiary institutions. To this end we propose an electronic payment system for the Rhodes University campus.
Rhodes University was chosen because we are familiar with the requirements for an electronic payment system at Rhodes University. Making recommendations for a closed system[37] is easier than for an open system, which would require years of careful analysis, because the consequences of implementing the incorrect system could be disastrous. Since Grahamstown is a small town, businesses rely on the students from Rhodes University for a significant portion of their income. Thus, any system implemented on the campus has a reasonable chance of being adopted by many merchants in Grahamstown.
1 Analysis of Requirements
We begin our analysis with a discussion of service transactions with a value less than one Rand[38]. Transactions involving goods, with a maximum value of R5500 have different requirements for auditing and security, and are discussed separately. The value of R5500 is chosen to approximately match the maximum value of ₤500 for Mondex cards. This is also sufficient to purchase all the necessary textbooks for the year.
1 Small Payments
There are currently many services on campus, such as photocopying and printing, which use a magnetic stripe card as a payment mechanism. The cost of these services ranges from 10c to 40c. Value is loaded onto the card through a machine which accepts coins in exchange for loading value onto the card. It is necessary that any payment system continue to support payments for such services as photocopying and printing.
The cost of Internet access in South Africa is high, and Rhodes University spends a large amount of money to ensure that researchers have access to the vast resources available on the Internet. As Internet content gets richer, and demand for Internet access increases[39], it may soon become too expensive to allow every student unlimited access to the Internet. Thus, it may be necessary to charge a nominal fee for access to the Internet. The system should support payments ranging in value from 1c to 10c for Internet access, which can be charged per time unit.
All of the above are service based, and involve the transfer of goods with nominal or no physical value. Since magnetic stripe cards, which are highly insecure, are currently being used for some of these services, we assume that security is not of paramount importance. Thus, we specify no auditing requirement, which would make the system more expensive by requiring each device offering a service to be connected to a central server. All of these services are offered by Rhodes University, removing the need to reimburse a third party for goods sold to a student. This allows us to remove value from the card, without keeping track of how much is spent.
There is little incentive on the part of consumers to break a system that only allows for small payments, since it is not worth the effort for a few free photocopies.
2 Large Payments
All other transactions fall into this category, such as purchasing a R3 coke from the tuck shop, or even R3000 worth of textbooks from the university booksellers. A system that allows for the purchase of textbooks worth thousands of Rands is likely to attract a lot more attempts to break the system. Thus, these transactions all require a high level of security, with audit capabilities.
If a student is on a bursary, the bursar often pays for textbooks and stationary. Currently, in order to buy a textbook, a student on a bursary has to fill in various forms, and wait for authorisation from student fees. Our system should cater for students on bursaries, by allowing bursars to set aside money that can be used for textbooks. It should be possible to spend this money to buy textbooks, and nothing else. This would also allow parents to give their children money, secure in the knowledge that it can only be spent to further their academic education. It should also be possible for a bursar to request a list of the transactions conducted with their money.
It should be possible to convert traditional cash into electronic money at any time of the day. It should also be possible to redeem electronic money for cash or a cheque.
Although credit cards and debit cards have been around for years, consumer use of electronic payments, and in particular digital cash, is still in its infancy. We believe that the university administration will require any electronic payment system to support traceable transactions. We also believe that it is in the student’s best interests to allow for anonymous payments. In order to reconcile these differences, we require our system to allow for partially anonymous payments. Partially anonymous payments are ultimately fully traceable, but allow the link between the withdrawal of a coin, and the spending of a coin to be obscured. With the cooperation of the correct parties, the traceability of the system can be fully restored[40].
Our system should cater for peer-to-peer payments. Off-line peer-to-peer payments are expensive to support, and difficult to implement. Something similar to the Mondex wallet, which facilitates off-line peer-to-peer payments, would have to be given to each student, making the overall system expensive. Thus, we require our system to support on-line peer-to-peer payments.
Rhodes University has only a limited budget for the purchase of computer equipment, so the system should be scalable. This would allow the system to grow to the rest of Grahamstown without incurring a significant expense to Rhodes University.
Lastly, the coins should be deposited back into a student’s account at the end of the university year, and new coins issued at the beginning of the next year. This adds an extra degree of security, improves scalability, and allows for system upgrades to take place during the summer vacation.
3 Classifying the Requirements
Our system needs to be secure, partially anonymous, off-line, portable (on campus at least), widely accepted (on campus, and around Grahamstown), user friendly (to make it accessible to all students) and scalable. In addition, it needs to support on-line peer-to-peer transactions, micropayments and the ability for coins to expire at the end of every year.
2 Designing a System
The system we have developed in Chapter 5 is completely anonymous, and cannot easily be extended to support partially anonymous transactions. As this is one of our requirements, and we believe an important one in order to gain acceptance from the university administration, we propose the introduction of a new system. The PayMe system [Peirce et al, 1995] has most of the characteristics we need in such a system, including scalability and support for partial anonymity.
1 Quick Overview of PayMe
The three important operations available under the PayMe system are: withdrawing coins, depositing coins, and exchanging coins for new coins. Paying coins to the merchant is much the same as we have seen before. Confidentiality and integrity is ensured by using a public-key cryptosystem, allowing for encryption and digital signing.
Withdraw Coins
An account identifier, account name, account password, and amount are digitally signed by the account owner, and sent to the bank as a request for coins. As is evident, the withdrawing of coins does not provide anonymity, like our previous system. The bank takes the serial numbers of the coins, and inserts them into a database of issued coins. The PayMe system is scalable, since only issued coins are stored in the database, preventing it from growing indefinitely large.
Deposit Coins
Coins deposited into a bank account require the account identifier, name, and digital signature of the depositor to accompany the coin. The bank checks its database of issued coins; if the coin is in the database it has not been spent before, and is removed from the database (this is the reverse of the system developed in Chapter 5). The relevant account is then credited.
Exchange Coins for New Ones
Any user presenting a valid coin to the bank can exchange it for a new coin anonymously. This mechanism can be used to help hide the identity of the user. As we see later on, a trusted third party can be used to exchange coins for a user, and offer partial anonymity. If the trusted third party and the bank collude, the coins become traceable again.
2 Designing for Requirements
All students are issued with tamper resistant smart cards. Similar to the Mondex scheme, cards can be unlocked by inputting a PIN number, and locked by pressing a special lock button. The locking and unlocking of the card can only be performed by inserting the card into a suitable device, and using the keypad on that device to input a PIN number. Since the cards can only be used in certain devices, there is no need to provide another mechanism for unlocking the card.
Access control is enforced using public-key cryptography. This ensures that breaking one smart card and retrieving a secret key does not break the whole system. The smart card holds the public keys of all devices that are allowed read and modify bits. Some devices are only allowed to add value, while others can only subtract value, all this is built into the access control. A unique private key is also stored on each smart card. All communication between servers and the card, and between merchant readers and the card is encrypted using a session key, which is exchanged using a public-key cryptosystem[41].
In order to satisfy all our requirements, the smart cards issued are multi-function cards.
Since small payments require little security, and no audit trail, value is loaded onto the card for these payments by increasing a counter, and value is spent by decreasing this counter. The device at which the value is spent need not have a connection to a central server, since all that needs to be done is to decrease the counter. This device has a private key embedded in it that allows it to decrease the counter, and all requests to decrease the counter are signed with this private key. These devices are not able to increase the counter, as this requires signing the requests with a different private key (which the smart card can verify). Thus, only a small number of devices are able to increase the counter, and these can be placed in the library, or computer labs, to prevent people from tampering with them. The tamper resistance of the smart card ensures that only devices with the relevant private keys can alter the counter.
Smart card readers/writers can be installed on every computer, to require students to pay for Internet access. The price of installing the smart card readers will easily be recovered from what the students pay for Internet access[42]. If Internet access is provided in residence, then some form of prepaid Internet access system needs to be used, since giving our smart card reader/writers to students is expensive.
The above system satisfies the requirements for small payments, but does not provide enough security for large payments.
3 Designing for Large Payments
We propose using the PayMe system to provide basic coin issuing and redemption, with a slight modification, in that expiry dates are attached to each coin. To this end, Rhodes University needs to set up a secure server which acts as a mint. This server has a public/private key pair, and only coins signed by this server are considered valid. This server also contains the database of issued coins, and is responsible for detecting, and sometimes preventing, double spending.
1 Off-line
Since the PayMe system is designed to be an on-line system, where double spending is prevented by on-line verification, we need to modify it to cater for off-line payments. Rather than modify the protocols, tamper resistant smart cards are used to prevent double spending[43]. All purchases over R200 require on-line verification, to ensure that if the tamper resistance is broken, expensive fraud is prevented. The ability only to make small purchases should also deter people from trying to break the tamper resistance of the smart card. Coins are only transferred to devices that present a request signed by the appropriate private key, such as in a merchant’s device. Coins are also only accepted from devices that present the coins signed by the appropriate private key, such as in devices used to load cash onto the card[44].
2 Partial Anonymity
Partial anonymity is provided by a server that acts as a trusted third party in a coin exchange protocol. When coins are withdrawn, they are automatically given to this server, which exchanges them for new coins from the mint. This server then stores the serial number of the coins exchanged, so that a coin can be traced by combining this information with the information from the coin withdrawal that is stored in the mint. The ability to trace a coin is only available under certain circumstances, dictated by university policy. Thus, the anonymity of transactions is protected by university policy, and is not compromised even with full access to the central server.
3 Bursar Requirements
Satisfying the needs of bursars is more difficult. In order to ensure that the bursar’s money can only be spent on textbooks, we expand our system to include two different types of coins. The first type of coin is unrestricted, and can be spent at any merchant that accepts the coins. The second type of coin is restricted to certain purchases, such as textbooks and stationary.
The type of coin is determined by inserting a flag on the coin[45] (say U for unrestricted, and R for restricted) at the time of issue. When the coin is spent, the flag is checked to ensure that a restricted coin is not spent on non-academic goods (such as pizza, or movie tickets). Restricted coins would always be spent before unrestricted coins, if the transactions allows for restricted coins to be used. This ensures that a students do not have to spend their own money on textbooks, when a bursar might have set aside money for that purpose.
The student fees division would need to modify the way money was kept in student accounts, since we need a way to differentiate between restricted and unrestricted value. (We are not familiar with how value is stored in student accounts, but we assume this extension is possible.)
If restricted coins are deposited back into a student’s account, they are flagged as restricted value in the account, and can only be withdrawn as restricted coins. Unrestricted coins are similarly deposited as unrestricted value.
If a bursar wishes to receive a list of the transactions that they paid for, the restricted value in a student’s account is marked as traceable. When coins are issued, they are not exchanged using the trusted third party, but directly transferred to the student’s smart card. The coins are also flagged (T for traceable, as opposed to restricted[46]), and when they are produced for redemption, the name of the merchant, and amount spent, is entered into that particular student’s transaction database[47].
4 Peer-to-Peer Payments
Devices are set up around campus (In residences, in the library, computer labs, etc.) with the privileges to transfer and deposit coins onto a smart card. These devices are linked to the central server, and contain a keypad for entering an amount. Two smart cards are inserting into the device to transfer coins from one card to another. Peer-to-peer payments are made by transferring the coins from one smart card to another, and then exchanging those coins for new coins from the mint. All of this is done on-line, so there is no possibility of double spending. Only unrestricted coins can be transferred. This is enforced both by the device transferring the coins, and the central server that only allows the trusted server to exchange coins. Such devices would also be used to check the balance on a card.
5 Loading Cash
Coins are loaded onto the card in one of two ways. The first way involves a direct transfer of value from a student’s account, which can be done at the Student Bureau. This allows restricted value from bursars to be transferred onto the card, as well as unrestricted value (such as a fees discount). The process involved is similar to withdrawing money from a bank account, and all that is required is for the central server to mint coins to the value being withdrawn, and debit the student’s account. It is assumed that the central server trusts the computer that keeps track of student accounts.
The second way involves loading cash onto the card, in the form of unrestricted coins. This can be done by using coin ‘vending machines’, which accept paper cash and coins in exchange for electronic coins. Since these devices are likely to hold a large amount of paper money, they should be placed in the library and Student Bureau, to prevent tampering, and theft of the money.
6 Depositing Cash
Coins are deposited into a student’s account at the Student Bureau. All students need to do this at the end of the year, to ensure their coins do not expire. Money can then be withdrawn from a student account in the same way as it is currently, by requesting a cheque from the university.
4 Concerns
Even though double spending can be detecting, and prevented for payments over R200, the double spender is not known. Rhodes University has no idea whether the merchant or the student attempted to double spend. The system is relatively immune to large scale double spending, since all transactions can be made traceable. If attempts to double spending are detected many times from the same student, or the same merchant, the university can investigate, and possibly lay charges of fraud.
It is possible, if complicated, to bind a name to a digital coin, in much the same way as our system in Chapter 5. The complication is caused through the use of a trusted third party to provide partial anonymity. This third party would need to ‘rebind’ a name to the new digital coin that it requests. This makes the third party a more attractive target, since compromising it would enable someone to frame another student (but not merchant) for double spending.
Rhodes University is not a bank, and does not have the relevant security procedures in place to protect the central server from unauthorised access. It would be wiser to get a banking institution to develop a ‘campus card’ for Rhodes University, that satisfied all the above attributes. Anonymity could still be controlled by Rhodes University, through the implementation of a trusted third party on campus. If the security of the trusted third party were to be compromised, the attacker would not be able to mint digital coins, or even defeat the anonymity of the system[48]. Some form of Electronic Data Interchange (EDI) would need to be implemented between the bank’s central server, and Rhodes University student fees[49].
5 Looking Ahead
We have not yet explored the possibility of creating a private value unit, such as the Rhodes Dollar, which could only be used around Grahamstown. Rhodes could offer tutors a choice of earning say, R500 a month, or 600 Rhodes Dollars a month. The 600 Rhodes Dollars would have the same value as R600, but only be redeemable in Grahamstown. Grahamstown merchants could then offer Rhodes some form of compensation if it were to pay its student employees in Rhodes Dollars, since this would mean increased business for the merchants around Grahamstown.
Extending our system to cater for more than two types of coins is trivial. It is possible to have ‘Internet payment coins’ and allow for some initial quota of these coins to be given to all students. This quota could depend on the requirements of the courses they are registered for. Similarly, students from disadvantaged backgrounds could be given free Internet access, by providing them with a large enough initial quota.
6 Review
We have discussed a digital cash system that could be used at Rhodes University to allow Rhodes to offer a ‘cashless campus’. Such a system would need to be secure, portable, widely accepted, user-friendly, and scalable. It should allow for on-line peer-to-peer payments, and should support micropayments, and the ability to expire coins at the end of each year. The most interesting, and we believe extremely important, feature required by our system is partial anonymity.
Tamper resistant smart cards are used together with a counter to support micropayments. The PayMe system is extended for our purposes. Since the PayMe system is essentially on-line, it is extended off-line by relying on the tamper resistance of the smart cards for payments under R200. Partial anonymity is provided by using a trusted third party to exchange coins after they are withdrawn.
Our system caters for two different types of coins, restricted and unrestricted. Restricted coins are issued to allow students to purchase textbooks and stationary, and unrestricted coins can be used to purchase anything at any store that accepted the digital coins. Such a system can be extended to allow for traceable coins to be issued.
It is possible for Rhodes University to become a cashless campus, and in so doing, provide a better service to bursars and students, and improved safety for everyone on campus.
Conclusions and Future Research
1 Conclusion
A true digital cash system is secure, anonymous, off-line capable, portable, two-way, divisible, widely accepted, user-friendly, and allows for unit-of-value freedom. We have discussed coins of infinite duration, and concluded that it is too dangerous to implement a system that allows for coins of infinite duration. These ten attributes parallel the important attributes of traditional cash, and are sufficient to create a system that is the electronic equivalent of paper cash. Since we are creating a new form of cash, we do not need to be shackled to the limitations of traditional cash. We have proposed two more features: the ability to make micropayments, and conditional repudiation and recovery of digital coins, that extend the functionality of digital cash beyond that of traditional cash. In addition, we have proposed that a digital cash system should be scalable, allowing it to economically service an ever increasing number of users.
It is foolish to entrust the security of a digital cash system to the tamper resistance of a smart card alone. Thus, protocols have been developed which allow for a secure, anonymous, off-line digital cash system to be implemented. Security is achieved by using public-key cryptography to ensure confidentiality, integrity, and authenticity. Anonymity is achieved through the combined use of blind signatures, and the cut and choose protocol. The off-line capability is achieved by binding a user’s name into a digital coin in such a way that spending it twice reveals the identity of the user, but spending it once does not.
On-line peer-to-peer payments, and divisibility are easily achieved through the use of a coin exchange protocol, which exchanges old digital coins for new ones. Off-line peer-to-peer payments, and divisibility are more difficult to implement, and we have not been able to extend our system to include these two attributes.
Portability, wide acceptance, and unit-of-value freedom are largely independent of the technical specifications of the digital cash system, and depend more on political and economic circumstances.
A digital cash system is capable of supporting micropayments, provided the storage, processing, and communication costs are less than the value of the payment. Conditional repudiation and recovery are easily supported in an on-line system, where double spending is prevented. We have been unable to support conditional repudiation and recovery in an off-line system. The scalability of a system depends on how the database of spent coins grows. If the database continues to grow indefinitely, the cost of detecting double spending increases all the time. We have extended our digital cash system to expire coins after a year, thereby limiting the size of the database, and increasing the security of the system.
iKP and SET were developed to allow for secure credit card transactions on the Internet, and the creation of a undeniable audit trail. This is achieved through the extensive use of digital signatures, and public-key cryptography. iKP and SET are not a form of digital cash, but rely on the existing credit card infrastructure to transfer value.
1 Rhodes University
We have used the Rhodes University campus as a case study, and have proposed a suitable digital cash system, based on the requirements of the university campus. Such a system would need to be secure, portable, widely accepted, user-friendly, and scalable. It should allow for on-line peer-to-peer payments, and should support micropayments, and the ability to expire coins at the end of each year. The most interesting, and we believe extremely important, feature required by our system is partial anonymity.
The use of tamper resistant smart cards has been proposed together with a counter to support micropayments. Larger payments would be supported by extending the PayMe system, and using the tamper resistance of the smart card to support smaller off-line payments. Partial anonymity would be provided through the use of a trusted third party to exchange coins after they are withdrawn.
Two types of coins, restricted and unrestricted, might be created to allow students to purchase textbooks with money from a bursar. This same money could not be spent on entertainment, or other non-academic endeavours. Restricted coins could be modified, to become traceable, should the bursar wish to receive a list of transactions the student has paid for with their money. Unrestricted coins could be used to purchase anything.
It is possible for Rhodes University to become a cashless campus, and in so doing, provide a better service to bursars and students, and improved safety for everyone on campus.
2 Future Research
We believe it is important to implement and test the digital cash system proposed for Rhodes University. Future projects in this area could create a pilot system that
can be used to convince the university administration to turn Rhodes into a ‘cashless campus’. The challenges faced and overcome in implementing the system would be informative when the system is implemented throughout campus.
The study of electronic cash is still in its infancy, and requires cooperation among the disciplines of Economics, Law, Mathematics, and Computer Science. Thus, this project could be extended in any of those areas. The economic and legal effects of digital cash are not obvious, yet are an important guide in implementing the correct system. It is up to the disciplines of Mathematics and Computer Science to develop a secure system that meets all the required technical specifications.
References
|[Anderson et al, 1996] |Anderson, Ross, Kuhn, Markus, Tamper Resistance – a Cautionary Note, 1996. |
|[Beenz] |beenz, . |
|[Bortner, 1996] |Bortner, Mark, Cyberlaundering : Anonymous Digital Cash and Money Laundering, |
| |, 1996. |
|[Brands, 1994] |Brands, Stefan, Electronic Cash on the Internet, , October |
| |1994. |
|[Chaum, 1993] |Chaum, David, Online Cash Checks, cypherpunks-list #6929, |
| |, 1993. |
|[Clarke, 1996] |Clarke, Roger, Identification, Anonymity and Pseudonymity in Consumer Transactions: A Vital |
| |Systems Design and Public Policy Issue, |
| |, October 1996. |
|[Flooz] |Flooz : Online gift currency sent by e-mail with a greeting card for any occasion or holiday, |
| |. |
|[Froomkin, 1996] |Froomkin, A. Michael, Flood Control on the Information Ocean: Living With Anonymity, Digital Cash,|
| |and Distributed Databases, , 1996. |
|[Grabbe, 1998a] |Grabbe, J. Orlin, Digital Cash and the Future of Money, , |
| |1998. |
|[Grabbe, 1998b] |Grabbe, J. Orlin, Concepts In Digital Cash, , 1998. |
|[Grabbe, 1998c] |Grabbe, J. Orlin, Internet Payment Schemes: Part 1, , 1998. |
|[Grabbe, 1998d] |Grabbe, J. Orlin, Internet Payment Schemes: Part 3, , |
| |1998. |
|[Koblitz, 1994] |Koblitz, Neal, A Course in Number Theory and Cryptography (Second Edition), Springer-Verlag New |
| |York, Inc., 1994, Chapters 1-3, pp. 1-22. |
|[Matonis, 1995] |Matonis, Jon W., Digital Cash & Monetary Freedom, |
| |, April 1995. |
|[McCullagh et al, 2000] |McCullagh, Adrian, Caelli, William, Non-Repudiation in the Digital Environment, |
| |, July 2000. |
|[Menezes et al, 1996] |Menezes, A., van Oorschot, P., Vanstone, S., Handbook of Applied Cryptography, CRC Press, |
| |, 1996, Chapters 1, 8, pp. 2, 16, 26, 28, 31, 32, 294. |
|[Network Associates, 1999] |Network Associates, Inc., An Introduction to Cryptography, |
| |, 1999, pp. 11, 16, 17, 19, 20, |
| |30-33, 45. |
|[Orwell, 1967] |Orwell, George, Nineteen Eighty-Four, Penguin Books, 1967. |
|[Peirce et al, 1995] |Peirce, Michael, O'Mahony, Donal, Scalable, Secure Cash Payment for WWW Resources with the PayMe |
| |Protocol Set, , 1995. |
|[Schneier, 1996] |Schneier, Bruce, Applied Cryptography (Second Edition), John Wiley & Sons, Inc., 1996, Chapters 1,|
| |2, 3, 4, 5, 6, pp. 1-5, 35-41, 44-71, 86-89, 103, 112-115, 118-124, 140, 145. |
|[Rivest et al, 1998] |Rivest, Ronald L., Shamir, Adi, PayWord and MicroMint: Two simple micropayment schemes, May 1996. |
|[Wayner, 1996] |Wayner, Peter, Digital Cash - Commerce On The Net (2nd Edition), Academic Press, 1996, Chapters 2,|
| |3, pp. 25-27, 40, 41, 55-65, 123-129, 159-173. |
Appendix A: Bibliography
Cryptography
Abelson, Hal, Andersen, Ross, Bellovin, Steven M., Benaloh, Josh, Blaze, Matt, Diffie, Whitfield, Gilmore, John, Neumann, Peter G., Rivest, Ronald L., Schiller, Jeffrey I., Schneier, Bruce, The Risks Of Key Recovery, Key Escrow, & Trusted Third Party Encryption, , 1998.
The U.S. government (and other governments around the world) have proposed many different 'key recovery' systems, designed to aid law enforcement's surveillance efforts. The scale of key recovery demanded by governments, along with various other requirements, are not the same as that for individual users or large corporations, which introduces extra costs into such a system. Key recovery will also make critical infrastructure more vulnerable. The costs and risks of key recovery by governments, as well as the implications thereof, are discussed in this report.
Bach, Eric, Bellovin, Steve, Bernstein, Dan, Bolyard, Nelson, Ellison, Carl, Gillogly, Jim, Gleason, Mike, Gwyn, Doug, O'Connor, Luke, Patti, Tony, Setzer, William, sci.crypt FAQ, , June 1999.
A broad overview of everything cryptographic, from the basics of cryptography, through to the mathematics behind ciphers and public key systems, and cryptanalysis. Numerous references are given for each section.
Schneier, Bruce, Why Cryptography Is Harder Than It Looks, , 2000.
Bruce Schneier gives a sobering view on what cryptography can and cannot do. Cryptography is not a 'silver bullet', and cannot solve confidentiality problems alone. The implementation of cryptographic algorithms is much more difficult, and even then there may be other ways to extract the information.
Shay, William A., Understanding Data Communications & Networks (Second Edition), Brooks/Cole Publishing Company, 1999, Chapter 4, pp. 245-277.
This chapter offers a general overview of encryption schemes that have been used, including substitution ciphers, transposition ciphers and DES. A concise explanation of the Diffie-Hellman key exchange is given.
Digital Cash
Clarke, Roger, The Mondex Value-Card Scheme: A Mid-Term Report, , February 1996.
Mondex is one of the more mature electronic purse schemes available, and has undergone many tests throughout various parts of the world. Although this article is a bit dated, it offers a good overview of the Mondex system, and the potential implications for privacy, fraud, and other socially important issues.
Brands, Stefan, Various papers by Stefan Brands are available at .
Some good ideas on creating a secure, offline, anonymous cash system are presented in these papers, as well as mathematical proofs for most of the concepts.
E-Commerce
Clarke, Roger, Electronic Commerce Definitions, , February 1999.
Definitions and explanations of some terms in electronic commerce, such as electronic publishing and electronic services delivery.
Clarke, Roger, Net-Based Payment Schemes, , 1996.
An overview of different electronic payment options available is presented in this article. It is not very technical in nature, but offers references to more technical documents under each payment option.
Clarke, Roger, Promises and Threats in Electronic Commerce, , August 1997.
Trust in the 'real' world is established in various 'physical' ways, such as handshakes, and body-signals. None of this is available in the electronic world of the Internet, so other ways have been designed to allow for authentication. Clarke discusses the different kinds of authentication available, as well as the impact that widespread identification and authentication may have on society.
Clarke, Roger, The SET Approach to Net-Based Payments, , November 1996.
A quick overview of SET (Secure Electronic Transaction), a standard developed by MasterCard and VISA to facilitate secure credit card transactions on the Internet.
Kosiur, David, Understand Electronic Commerce, Microsoft Press, 1997.
Electronic commerce is more than just electronic payment mechanisms. It is a whole strategy, encompassing marketing, manufacturing, payment and delivery. Electronic payment systems are discussed, and put into the context of electronic commerce as a whole. This book is not very technical, but offers a good strategic overview of electronic commerce.
Economic Issues
Bernkopf, Mark, Electronic Cash And Monetary Policy, , 1996.
What makes digital cash a form of cash, and how does the 'money' in your photocopy card differ from cash? The existence of a form of currency does not depend on its being backed by the government, but currency that is not backed and regulated poses certain challenges. This article examines some of the issues surrounding the creation of an electronic currency, including taxation and the development of private currencies.
Clarke, Roger, The Monster from the Crypt: Impacts and Effects of Digital Money, , 1997.
Roger Clarke discusses some of the socio-economic issues surrounding digital money, and its effect on government funded services. Jurisdiction is discussed in relation to taxation and law enforcement, and the Internet's 'supra-jurisdictionality' is explored further.
Clarke, Roger, The Willingness of Net-Consumers to Pay: A Lack-of-Progress Report, , 1999.
Up until now, commerce on the Internet has been a resounding failure. Most attempts at creating a profitable business model have been less than successful. Clarke likens the Internet to a community, and discusses the failure of commerce on the Internet in relation to this community. Old business models used on the Internet (such as Push-Technology) are analysed, and reasons for their failures given.
De Long, J. Bradford, Froomkin, A. Michael, The Next Economy?, , April 1997.
The great economist of the 18th century, Adam Smith said, “...every individual... endeavours as much as he can... to direct... industry so that its produce may be of the greatest value... neither intend[ing] to promote the public interest, nor know[ing] how much he is promoting it... He intends only his own gain, and he is in this, as in many other cases, led by an invisible hand to promote an end that was no part of his intention... By pursuing his own interest he frequently promotes that of society more effectually than when he really intends to promote it...”
In this article, Froomkin and De Long discuss how modern technologies are undermining the features (excludability, rivalry, transparency) that make Adam Smith's invisible hand an effective system for organising production and distribution. Specific emphasis is given to how electronic commerce, and the purchasing of digital media (E.g. software) changes the economic playing field.
Good, Barbara A., Will Electronic Money Be Adopted in the United States?, Working Paper 98-22, Federal Reserve Bank Of Cleveland, , 1998.
The demise of cash, and the emergence of electronic money has been predicted for some time now. In Europe and Asia, electronic purses seem to be gaining acceptance much faster than in the U.S.. This paper examines some of the reasons why U.S. consumers are slow to adopt this new technology, and ways in which it could be made more attractive to the consumer.
Griffith, Reynolds, Cashless Society or Digital Cash ?, , March 1994.
As with any innovation, there are barriers to its public acceptance. Griffith examines some of the barriers to achieving a cashless society, and offers an overview of digital cash systems that could reduce consumer resistance to this ‘cashless society’.
Mester, Loretta J., The Changing Nature of The Payments System: Should New Players Mean New Rules?, Business Review, Federal Reserve Bank of Philadelphia, March/April 2000.
This article offers an overview of the payment systems currently in use in the U.S.. Smart card payments, and payments over the Internet are discussed, and compared to the ‘traditional’ payment methods (cash, cheque, and credit card). Reasons are given for the slow adoption of smart cards and other electronic forms of payment in the U.S..
Muscovitch, Zak, Taxation of Internet Commerce, , 1997.
Taxes are a governments source of income, to provide services such as maintaining roads, police departments, and public hospitals. Commerce on the Internet enables businesses (and soon consumers) to avoid national tax laws. This article discusses some laws currently in place to prevent tax avoidance, and the implications that tax avoidance would have on governments.
Tanaka, Tatsuo, Possible Economic Consequences of Digital Cash, , 1996.
This article gives a basic introduction to digital cash, before addressing some of the economic issues surrounding digital cash. The transnationality of digital cash is presented as an important characteristic, which has both positive and negative consequences. Positive effects include an increase in efficiency of monetary transactions, and decrease in the cost of transfer. The author is concerned that widespread ‘cash backed’ digital cash could cause a destabilisation of foreign exchange rates, and adversely affect money supply in the real world.
Wenninger, John, Laster, David, The Electronic Purse, Current Issues In Economics And Finance, Federal Reserve Bank Of New York, April 1995.
The Electronic Purse is what we might use to conduct all small value transactions in the future. This paper discusses how an electronic purse would work, as well as the implications it would have for banks and the national treasury.
Mathematics
Durbin, John R., Modern Algebra: An Introduction (3rd Edition), John Wiley & Sons Inc., 1992.
A formal introduction to algebra, including groups, and integers modulo n. These concepts are needed for an understanding of the mathematics behind the RSA crypto scheme, and why it works.
Political Issues
Froomkin, A. Michael, The Unintended Consequences of E-Cash, , March 1997.
A quick overview of some of the consequences of electronic money, and anonymous electronic cash in particular.
Grabbe, J. Orlin, The End Of Ordinary Money, & , 1995.
These two essays explain some of the politics surrounding cryptography, privacy, and the U.S. government's ability to track almost any transaction. They offer a broad overview of the issues involved, not just with digital cash, but electronic payments in general.
Grabbe, J. Orlin, Digital Cash and the Regulators, , 1998.
Some of the legal issues surrounding digital cash systems are dealt with in this essay. The laws discussed are U.S. banking laws and regulations, but it gives an overview of the non-technical challenges to be overcome in implementing a digital cash system.
Security
Loscocco, Peter A., Smalley, Stephen D., Muckelbauer, Patrick A., Taylor, Ruth C., Turner, S. Jeff, Farrell, John F., The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments, , November 1998.
At the heart of all computer security is the operating system, and any security threats cannot be adequately addressed without secure operating systems. In this essay some critical operating system security features are discussed (such as Mandatory Security and Trusted Paths) and contrasted with the inadequate security mechanisms of modern operating systems.
Schneier, Bruce, Secrets & Lies - Digital Security in a Networked World, John Wiley & Sons, Inc., 2000.
In this book a wide range of topics about security are discussed, from Cryptography to the human element necessary for security. Schneier offers us a new way to look at security, one where preventing malicious attacks is impossible. His solution to this problem is ‘Risk Management’, and he outlines methods by which we can achieve this.
Senderek, Ralf, The Protection Of Your Secret Key, , October 1998.
The article focuses on the security of Pretty Good Privacy (PGP), a software program that allows users to perform various forms encryption (symmetric and asymmetric) and authentication (based on public keys, using a ‘Web of Trust’ model). Various attacks on the algorithms used by PGP (RSA, MD5, IDEA) are discussed, as well as other more practical attacks (such as exploiting vulnerabilities in the operating system).
Simpson, S., PGP DH vs. RSA FAQ, , September 1999.
This article is an excellent introduction to the world of cryptography. All the relevant algorithms (E.g. RSA, DH/ElGamal, DSS, IDEA, CAST, MD5, SHA-1 etc.) are discussed in a fairly technical manner. The concepts needed for encryption and authentication (hash functions, digital signatures, etc.) are also presented. All of this is put into the context of PGP, which is also discussed in detail.
General
Chaum, David, Prepaid Smart Card Techniques: A Brief Introduction and Comparison, , 1994.
A brief introduction to the different kinds of smart cards available in 1994. It is most likely out of date by now.
Clarke, Roger, Human Identification in Information Systems: Management Challenges and Public Policy Issues, , 1994.
What do we mean by human identity, and the ability to identify someone ? Being concerned with anonymous electronic commerce, it makes sense to look at what constitutes someone's identity. Clarke discusses the characteristics of human identity, and various schemes which could be used to identify an individual. The social and economic aspects of setting up a universal identification system are dealt with.
Clarke, Roger, Privacy Issues in Smart Card Applications in the Retail Financial Sector, , March 1996.
Clarke examines privacy issues surrounding smart cards. The privacy inherent in some of the smart cards available today is discussed, as well as future directions in privacy regulation.
Clarke, Roger, The Digital Persona and its Application to Data Surveillance, , June 1994.
Who are we in the digital world ? Clarke discusses this, and other issues that arise from having a digital persona.
Clarke, Roger, Trails in the Sand, , May 1996.
These days almost anything we do leaves a data trail. These trails can be used by governments, law enforcement, and many other corporations to track where we are, and what we do. Clarke examines some of the technologies that create these data trails for us.
Froomkin, A. Michael, The Essential Role of Trusted Third Parties in Electronic Commerce, , October 1996.
Cryptographic techniques, such as public-key crypto schemes and digital signatures, are not sufficient to provide secure electronic commerce. Certification Authorities (CAs), which can bind digital signatures to identities, are a necessary part of most e-commerce transactions. Froomkin gives an overview of the cryptographic techniques needed for electronic commerce, and then discusses the role of CAs (The ‘Trusted Third Party’) more in depth. The legal aspects of digital signatures and the liability for the issuing of erroneous certificates are dealt with as well. This article is written from a non-technical, legal standpoint.
Froomkin, A. Michael, The Internet As A Source Of Regulatory Arbitrage, , 1996.
Certain countries have, in the past, tried to limit the free flow of information by imposing strict laws which prevent people from publishing certain types of information. With the advent of the Internet, and anonymous remailers, it becomes difficult to enforce these laws. The ability both to publish and read articles anonymously gives people everywhere freedom of speech. Froomkin deals with ways in which people can express their views anonymously on the Internet, and use the Internet to circumvent local regulations, as well as some of the consequences thereof.
Van Hove, Leo, Electronic Purses: (Which) Way to Go?, , July 2000.
When electronic cash cards first came out, they were going to take over the world. Analysts had predicted that by 2000 cash would be almost extinct. They were wrong. This article offers an overview of what happened with electronic purses (EPs), and paints a picture of a long, hard road to public acceptance. Statistical data of many of the EPs available in Europe is given, and Van Hove makes an attempt at explaining it.
Glossary
|access control |Restricting of access to resources, by allowing only privileged access to resources. |
|anonymous transaction |A transaction where no identification data is presented. |
|asymmetric algorithm |See public-key algorithm. |
|biometrics |Using biological properties to identify an individual, such as fingerprints or voice |
| |recognition. |
|bit commitment |Encrypting a bit (or series thereof) in such a way that it can only be decrypted to |
| |produce the original bit that was committed to. |
|blind signature |A signature on a document, such that the signer does not know the document contents, and|
| |cannot link the document to the act of signing the document, should he receive the |
| |document at a later date. |
|blinding factor |A random number used to obscure the contents of a message, in order to allow for a blind|
| |signature to be attached. |
|brute force attack |An attack in which every possible key in the keyspace is tried until the correct |
| |decryption is found. |
|certification authorities |A certification authority binds a person’s name to a particular public key. The CA |
| |checks up on a person’s identity to ensure that they are who they say they are. |
|challenge string |An n-bit string a merchant sends a consumer that determines which half of the consumer’s|
| |identity is unlocked. This is used to detect double spenders in an offline digital cash|
| |system. |
|cipher |See cryptographic algorithm |
|ciphertext |The encrypted plaintext. |
|cleartext |See plaintext. |
|closed system |A payment system, which only offers a few possible uses. E.g. photocopy cards and |
| |telephone cards. |
|collision-free |A property of a one-way hash function that makes it difficult to generate two messages |
| |that hash to the same message digest. |
|cryptographic algorithm |A mathematical function used to encrypt plaintext and decrypt ciphertext. |
|cryptosystem |A cryptographic algorithm, together with all possible plaintexts, ciphertexts, and keys.|
|cyberpayment system |An electronic money system based entirely on software systems. |
|data trail |A collective term used to describe the data that is collected about an individual when |
| |they engage in electronic (or paper) transactions |
|decryption |Process of revealing the ciphertext, but converting it into the original plaintext. |
|digital cash |An electronic equivalent to cash, which maintains the same characteristics (E.g. |
| |anonymity). Digital tokens are used as units of value to replace paper tokens. This is|
| |not to be confused with electronic money. |
|digital persona |An abstract model of a person, obtained by analysing their data trails. |
|digital signature |The signed hash value of a message, which is normally sent together with the message. |
|double spending problem |Digital tokens are just a series of bits, and can thus be copied easily. If these bits |
| |were to represent value, the double spending problem refers to the ability to copy these|
| |bits, and spend them twice. |
|Ecash |An electronic cash system from DigiCash, which offers payer anonymity. It is an on-line|
| |system. |
|e-cash |See digital cash. |
|EFT |See Electronic Fund Transfer. |
|electronic cash |See digital cash. |
|Electronic Fund Transfer |An electronic payment mechanism used to transfer funds between banks over a private |
| |network. |
|electronic money |Any form of currency that is electronic. |
|electronic purse |A prepaid card which is used in an open system. |
|encryption |Process of hiding the contents of a message, producing ciphertext. |
|hard problem |A problem that is difficult to solve, computationally. |
|hash function |A mathematical function that takes a variable-length input and produces a fixed length |
| |output. |
|hybrid cryptosystem |A cryptosystem that uses a combination of asymmetric and symmetric algorithms to encrypt|
| |messages. |
|identified transaction |A transaction in which the data generated by that transaction can be easily related to |
| |an individual. |
|iKP |Internet Keyed Payments |
|Internet Keyed Payments |A family of on-line payment protocols developed by IBM to facilitate the secure transfer|
| |of credit card details over the Internet. |
|key |A value that is used together with a cryptographic algorithm when encrypting or |
| |decrypting. Encryption and decryption are dependent on the key. |
|keyspace |The range of all possible values for a key. |
|man-in-the-middle attack |An impersonation attack on public-key cryptography, which enables Mallet to read and |
| |modify all communication between Alice and Bob. |
|message digest |The fixed length output of a hash function. |
|micropayments |Very small payments, that could be used to pay for viewing a web page over the Internet,|
| |typically ranging from one tenth of a cent to one cent. |
|Mondex |An electronic purse scheme which allows consumers to conduct secure transactions with |
| |merchants, and among themselves using a Mondex wallet. |
|Mondex wallet |A device that allows value to be transferred from one Mondex card to another. |
|monetary freedom |The ability of individuals and organisations to establish, circulate, and trade their |
| |own private currency. |
|NetCash |An electronic cash system that offers limited anonymity, but very good scalability. |
|non-repudiation |Preventing the denial of previous commitments or actions (such as signing a message). |
|number theory |A branch of mathematics that investigates the properties of numbers, and their |
| |relationships with each other. |
|offline electronic money |An electronic money scheme where the merchant can confidently accept payment from a |
| |consumer without having to validate it at a bank first. E.g. Mondex, and an offline |
| |electronic cash scheme devised by Stefan Brands [Brands, 1994]. |
|one-way hash function |A hash function with the additional property that it is difficult to produce a message |
| |that hashes to a particular message digest. |
|online electronic money |An electronic money scheme where the merchant is required to contact the bank to |
| |validate a consumers payment before it can be accepted. E.g. DigiCash. |
|open system |A payment system , which can be used in a wide variety of locations, for a broad range |
| |of purchases. E.g. Paper cash, and credit cards. |
|PayMe |A scalable, secure electronic cash system that tries to combine the best features of |
| |Ecash and NetCash. It is an on-line system. |
|perfect crime |A crime that affords the police no opportunity to apprehend the criminal. |
|PGP |See Pretty Good Privacy. |
|PKI |See public key infrastructure. |
|plaintext |Human readable message before it is encrypted. |
|Pretty Good Privacy |A popular e-mail encryption program developed by Phil Zimmermann. |
|private key |The private part of the key used in public-key cryptography. It must be kept secret. |
|pseudonym |An identifier for an individual in a transaction which is not easily associated with a |
| |particular person. |
|public key |The public part of the key used in public-key cryptography. It is made widely |
| |available, and is viewable by anyone. |
|public key infrastructure |A widely available and accessible certificate system used to obtain and verify the |
| |authenticity of an individual’s public key. |
|public-key algorithm |A cryptographic algorithm that uses one key to encrypt data, and another to decrypt |
| |data. |
|public-key cryptography |Cryptography that uses a public-key algorithm. |
|RSA algorithm |A public-key algorithm developed in 1978 by Rivest, Shamir, and Adleman that gets its |
| |security from the difficulty we have in factoring large numbers. |
|scalable |The ability of a digital cash system to scale up to service more users, as their number |
| |grows. |
|secret splitting |The process of splitting a secret into two (or more) parts, such that any part by itself|
| |contains no information about the secret that was split. The XOR function is usually |
| |used to split secrets. |
|secret-key algorithm |A form of symmetric algorithm, where the encryption and decryption key are exactly the |
| |same. |
|secure channel |A line of communication where eavesdropping is impossible. |
|Secure Electronic Transaction |A standard developed by MasterCard and VISA to handle secure credit-card transactions |
| |over the Internet. |
|secure hash function |A one-way hash function that is collision-free. |
|Secure Sockets Layer |A protocol operating at the transport layer, developed by Netscape, that is used to |
| |provide secure Internet communication. |
|SET |See Secure Electronic Transaction. |
|SSL |See Secure Sockets Layer. |
|stored value card |See electronic purse. |
|symmetric algorithm |An algorithm where the encryption key can be derived from the decryption key, and |
| |vice-versa. |
|tamper resistant device |A hardware device that is extremely difficult to reverse engineer, or extract |
| |information from. |
|unlinkable transaction |A transaction where the bank cannot determine whether two given payments were made by |
| |the same person. |
|unsecured channel |A line of communication which can easily be eavesdropped on. E.g. any communication |
| |over the Internet. |
|untraceable transaction |A transaction where the bank cannot match withdrawals of money with deposits of the same|
| |money. |
|web of trust |A web of connected people, who trust some of the people they know to introduce them to |
| |new people. This is a way of associating a person with a public key. |
Index
access control 76
anonymous transactions 3, 27-29, 75
asymmetric algorithm 20
bit commitment 18, 20, 49, 50, 52, 59
blind signature 24, 29, 45, 85
blinding factor 24, 25, 46, 47, 50, 59
brute force attack 5, 19
certification authority 11, 12, 43, 63, 69
challenge string 50-52
cipher 5, 6
ciphertext 5, 6, 15, 22, 23
cleartext 5
coin exchange protocol 47, 52, 54, 56, 79, 85
collision-free 14, 20
cryptographic algorithm 5, 6, 92
cut and choose 46, 48, 50, 85
DigiCash 47
digital coin 3, 27, 30, 32, 34, 35, 38-40, 42-45, 47-60, 74, 82, 84, 85
digital signature 4, 11, 12, 15, 16, 20, 58, 62, 65, 76, 86
digital token 2, 3, 33, 35, 42, 54, 58, 70
double spending problem 27
ecash 95
electronic cash 3, 88, 98
Electronic Fund Transfer 1
hash function 13, 20, 21, 34, 58
Internet Keyed Payments 4, 62-64, 69, 70, 86
keyspace 5
man-in-the-middle attack 9, 11
message digest 13, 14, 16, 17
micropayments 31, 40, 58, 61, 75, 84-87
Mondex 53, 54, 72, 74, 76
Mondex wallet 74
monetary freedom 37
NetCash 60
non-repudiation 5, 17, 20, 70
off-line systems 30, 31, 40, 48, 51, 54, 56, 59, 61, 75, 78, 84-87
one-way hash function 13, 14, 17, 20, 21
on-line systems 30, 31, 45, 47, 48, 52, 53, 56, 59, 61, 62, 74, 75, 78, 80, 84, 86
PayMe 27, 47, 60, 61, 75, 76, 78, 84, 87, 91
perfect crime 29
PGP 10, 11
plaintext 5, 6, 12, 15, 23
private value unit 32, 37, 83
pseudonymous transactions 29
public key infrastructure 62, 63, 70
public-key algorithms 8, 12
RSA 21, 22, 23, 25
scalable 39, 40, 61, 74-76, 84-86
secret-key algorithms 6
session key 12, 77
SET 62, 69, 70, 86
SSL 69
symmetric algorithms 6
tamper resistance 41, 42, 48, 61, 76-78, 84, 85, 87
unlinkable 27, 56
untraceable 27, 33
web of trust 11
-----------------------
[1] As of this writing, a symmetric key of length 128 bits, and a public key of length 2048 bits are considered secure for the foreseeable future.
[2] There are also public key algorithms based on elliptic curve cryptography. This type of cryptography involves discrete logarithms on elliptic curves. The major advantage of elliptic curve cryptography is that it needs a much smaller key size in order to be secure (around 200 bits currently), making it faster.
[3] The villain in cryptographic literature is normally called Mallet. His ‘job’ is to read, modify, and disrupt communication between Alice and Bob.
[4] To do this Bob would probably get Carol to digitally sign his public key, attesting to its authenticity. We’ll discuss digital signatures in section 2.6.
[5] We’ll discuss digital signatures in section 2.6.
[6] We’ll discuss verifying digital signatures in section 2.6.
[7] This is due partly to the larger key size needed to make public-key algorithms secure.
[8] A session could be a single plaintext message, or a set of transactions performed with a web server. A session key is temporary, and changes with each plaintext message, or visit to a particular web site.
[9] If Alice were to repudiate her signature, the legal onus is on the other party to prove that she signed the document. To this end, witnesses would sign the document as well, testifying that Alice did, in fact, sign the document. Current digital signature laws in the U.S. reverse this, by requiring Alice to prove that she did not sign the document (E.g. she lost her private key) [McCullagh et al, 2000].
[10] In fact, it is almost impossible (computationally) to forge a digital signature without gaining access to the private key used to create the signature.
[11] This does not take into account someone losing their private key, or having it stolen. Once people lose control over their private keys, they should no longer be held accountable for signatures made with it [Schneier, 1996].
[12] By ‘hard’ we mean computationally infeasible. Such problems are normally of exponential order, and are referred to as NP-Complete, or intractable.
[13] Computers are programmable machines, so it is difficult to produce truly random numbers. Pseudorandom numbers can be generated, but these are not normally cryptographically secure (i.e. someone with the same pseudorandom number generator as ours can generate the same ‘random’ numbers). Randomness can be introduced by monitoring external objects, e.g. fluctuations in network traffic, user key presses, or mouse movements [Schneier, 1996].
[14] As we’ll see later, some off-line systems use tamper-proof smart cards for their security. We need to be able to spend digital cash on the Internet in order for it to be portable (We need to ‘take the cash onto the Internet’). As most computers do not have smart card readers, such a system would not be considered portable.
[15] Although there have been exceptions. A case in point is Russia, which recently refused to honour any 100 ruble notes printed prior to 1994 [Grabbe, 1998d].
[16] The system mints coins by finding collisions of hash functions. The security of the system depends on the mint having a more powerful computer than the users. If the coins did not expire, a user would eventually be able to mint coins, even though he has much less processing power.
[17] If Alice is kidnapped by aliens and returned a year later, she could be left with a lot of useless digital coins. In this case the bank may allow Alice to contact them in person, and discuss the situation. The bank would then perform a full check on Alice to satisfy themselves that Alice is not trying to cheat them, and exchange her old digital coins for new ones (minus a transaction fee, of course).
[18] Even if breaking the tamper resistance required the Class III opponent (well funded organisations) of [Anderson et al, 1996], the system would still not be safe. It would allow governments to wage ‘economic war’ on a country that used such a system. By flooding a country with illegal money they could destroy the value of its currency, sending the country into economic ruin.
[19] If this is a problem, the consumer and merchant could use a simultaneous secret exchange protocol [Schneier, 1996] in order to exchange the digital coin and a receipt of payment simultaneously.
[20] It is possible for the bank to have many different public/private key pairs, and coins signed with one private key can have a different value to coins signed with another private key.
[21] Certification Authorities can be used for this, but a bank’s security might require that it only trust public keys certified by the bank. Still, in order to prevent many other attacks, key exchange and authentication require more complex protocols than those discussed here.
[22] Alice may be willing to purchase goods from anyone, and not need to authenticate the merchant. There is nothing to stop a corrupt merchant from taking Alice’s digital coin, and not giving any goods in return. However, if a simultaneous secret exchange protocol was used to exchange the digital coin for a receipt of payment, Alice could dispute the transaction in court. Anyway, we assume that such a merchant won’t be in business very long.
[23] How they do this is beyond the scope of this project.
[24] Random numbers are chosen using a random number generator.
[25] Since the serial number is around 160 bits, there is about a 1 in 2160 chance of Alice choosing the same serial number as someone else.
[26] Whether the bank signs the full coin, or whether Alice blinds only the hash value of the coin, and gets the bank to sign that, does not make too much difference. If Alice only sends the bank blinded hash values, she would have to send the bank the actual coins along with the blinding factors when the bank asks her to unblind the 99 coins.
[27] This is because, in splitting the secret, Alice chooses a different random number for each I1,I2,…,I10.
[28] If this probability is too high, we can alter the system such that Alice attaches 20 or 30 identity strings when she withdraws a coin. The merchant would then produce a random 20 or 30-bit string, and Alice would open 20 or 30 halves of her identity. This makes the coin much larger, but with less chance of the system being defeated. Legal action may, however, dissuade people from trying to defeat the system.
[29] We regard this point of view as slightly pessimistic, since the science of cryptography is still in its infancy.
[30] Alice’s digital wallet could be her smart card, or a directory on her hard drive.
[31] David Chaum proposes a more efficient system, which does not need to create new coins each time change is given. It is an on-line system, and allows digital coins to be ‘split’ [Chaum, 1993].
[32] Biometric devices, such as fingerprint readers, have advanced to the point where they require a living person attached to the finger, and not just the actual finger. This should prevent people from stealing fingers along with the smart card.
[33] This can be done to offer a coin recovery service to people like Alice, who are kidnapped by aliens for a year. Even though the coins have expired, the bank still needs to check whether they have been spent before.
[34] The acquirer could issue certificates to all accredited merchants, allowing Alice easily to check whether a particular merchant is approved by the acquirer.
[35] And if Alice trusts the Certification Authority that signed the acquirer’s certificate.
[36] This is done to prevent the acquirer from knowing the details of the transaction. Of course, if the acquirer and merchant collude, Alice has no anonymity, thus Alice could choose to send the whole invoice.
[37] Recall, that a closed system is one in which only a few merchants accept payment by that system. In this case, Rhodes University campus acts as the merchant.
[38] The Rand, denoted by R, is the local unit of currency.
[39] Traditional journals are being replaced by electronic versions available on the Internet. As more resources become available on the Internet, students will be forced to do more research on the Internet, leading to greater demand for Internet access.
[40] This is similar to our earlier concept of pseudonymity, except now there is no form of identity escrow. Instead, information is stored which could link a particular student to a particular digital coin.
[41] The processor on a smart card is not extremely powerful, and encrypting everything with a public key would cause delays in the transaction.
[42] As a quick calculation, if 1c per minute is charged for Internet access, and the labs allow 250 students to use the Internet, and are full 8 hours a day, that means 1*250*60*8 cents per day, or R1200 per day.
[43] This is done by ensuring that coins with the same serial number are not spent twice. The smart card would need to maintain a list of all spent coins.
[44] The coin signed by the bank is signed again by the device. This signature is stripped off when the coin is stored on the card. This ensures that bogus coins cannot be loaded onto the card.
[45] Another way to differentiate the coins would be to have a different public/private key pair for each type of coin. This would require the smart card to store an extra public key, and offers little extra security, so we design the system using flags on the coin.
[46] Traceable coins are a subset of restricted coins, and can only be spent on the same goods as restricted coins.
[47] This ensures that we can create traceable coins without having to break the anonymity of restricted coins every time we want to trace a coin.
[48] To defeat the anonymity, an attacker would have to compromise both the trusted third party, and central server. Only then could they link purchases with student names.
[49] The structure of the data transferred can easily be specified using Extensible Markup Language (XML).
-----------------------
Alice
Carol
Acquirer
1: Invoice, and acquirer’s certificate.
2: Payment encrypted with acquirer’s public key.
3: Details of 2, and hash of Carol’s version of the transaction.
4: Confirmation of payment, signed by the acquirer.
Represents a digital signature on the information in the box.
Represents a digital signature on the information in the box.
4: Confirmation of payment, signed by the acquirer.
3: Details of 2, and hash of Carol’s version of the transaction, signed by Carol.
2: Payment encrypted with acquirer’s public key.
1: Invoice, acquirer’s certificate, and Carol’s certificate.
Acquirer
Carol
Alice
Represents a digital signature on the information in the box.
4: Confirmation of payment, signed by the acquirer.
3: Details of 2, and hash of Carol’s version of the transaction, signed by Carol.
2: Payment encrypted with acquirer’s public key, signed by Alice.
1: Invoice, acquirer’s certificate, and Carol’s certificate.
Acquirer
Carol
Alice
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- sell as an individual on amazon
- learning spanish as an adult
- my goal as an educator
- life as an orthopedic surgeon
- sell as an individual amazon
- life as an attorney
- feeling valued as an employee
- returning to college as an adult
- strong attributes as an employee
- annuities as an investment
- starting college as an adult
- finding x as an exponent