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.
i
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.
ii
Contents
1
Introduction ...................................................................................................................... 1
2
Cryptography – A Look Behind the Scenes ................................................................... 5
3
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
The Mathematics of Digital Cash ................................................................................. 21
3.1
4
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
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
iii
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
4.2.1
Micropayments ................................................................................................. 38
4.2.2
Conditional Repudiation and Recovery ........................................................... 38
4.2.3
Scalable ............................................................................................................ 39
4.3
5
Review ...................................................................................................................... 40
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
6
Optional Attributes of Digital Cash ......................................................................... 38
Review ...................................................................................................................... 61
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
iv
6.2
What is SET? ............................................................................................................ 69
6.2.1
7
6.3
What About Digital Cash? ....................................................................................... 70
6.4
Review ...................................................................................................................... 70
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
8
Benefits of SET ................................................................................................ 69
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
Conclusions and Future Research ................................................................................ 85
8.1
Conclusion ................................................................................................................ 85
8.1.1
8.2
Rhodes University ............................................................................................ 86
Future Research ........................................................................................................ 88
References ............................................................................................................................... 89
Appendix A: Bibliography..................................................................................................... 92
Cryptography.................................................................................................................... 92
Digital Cash ...................................................................................................................... 93
E-Commerce..................................................................................................................... 93
Economic Issues ............................................................................................................... 95
v
Mathematics ..................................................................................................................... 98
Political Issues .................................................................................................................. 98
Security............................................................................................................................. 99
General ........................................................................................................................... 100
Glossary ................................................................................................................................. 103
Index ...................................................................................................................................... 111
vi
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
vii
List of Tables
Table 6-1: iKP Security Levels ................................................................................................ 64
viii
1
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.
Page 1
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.
Figure 1-1: Electronic payment systems
Page 2
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.
Page 3
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.
Page 4
2
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.
2.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
Page 5
is found. A longer key makes it more difficult to launch a brute force attack, but also
makes encryption and decryption take longer1 [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.
Figure 2-1: Encryption and decryption
2.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:
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.
Page 6
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.
Figure 2-2: Securing communication with a secret-key algorithm
Page 7
2.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 logarithms2. 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.
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.
Page 8
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 Mallet3) 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 reencrypt 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.
3
The villain in cryptographic literature is normally called Mallet. His ‘job’ is to read, modify, and
disrupt communication between Alice and Bob.
Page 9
Both Alice and Bob believe that their communication is secure, not knowing that
Mallet is able to read, modify, and delete any message.
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
Page 10
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:
2.3.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 key4. 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.3.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 signs5. 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
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.
Page 11
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 signature6.
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.
2.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 session8. 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.
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.
Page 12
Figure 2-5: Encryption in a hybrid cryptosystem
Figure 2-6: Decryption in a hybrid cryptosystem
2.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
Page 13
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.
2.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
Page 14
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 repudiation9.
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 person10. 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.
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.
Page 15
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].
Page 16
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 message11. 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.
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].
Page 17
2.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.
Page 18
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 prearranged bit-string can be used. Provided the bit-string is long enough, it will prevent
Alice from cheating [Wayner, 1996].
2.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].
Page 19
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.
2.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.
Page 20
3
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.
3.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 hard12
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]:
12
By ‘hard’ we mean computationally infeasible. Such problems are normally of exponential order, and
are referred to as NP-Complete, or intractable.
Page 21
3.1.1 Generating a Key-pair in RSA
1. Choose two large numbers (in the range of 500-2000 bits) at random13. 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.
3.1.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.
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].
Page 22
3.1.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)
(by Euler’s Theorem [Koblitz, 1994])
= m mod n
3. Since we chose m < n we have not lost any information. m is the original
plaintext message.
3.1.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].
Page 23
3.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
= H(m)e mod n
Page 24
(Since kde mod n = k)
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.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.
Page 25
4
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.
4.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:
Page 26
4.1.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.
4.1.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].
Page 27
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?
Page 28
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
Page 29
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.
4.1.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
Page 30
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.1.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-andmortar’ stores. Any off-line capable system can easily be made portable by allowing
the cash to be copied onto a smart card14. Indeed, there are strong expectations that
mobile phones, which already have embedded smart cards, will become multifunctional 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.
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.
Page 31
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.
4.1.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.
Page 32
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.
4.1.6 Infinite Duration
It is still possible to spend bank notes that were printed ten or twenty years ago, as
paper cash does not expire15. 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.
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].
Page 33
Some systems, such as MicroMint [Rivest et al, 1998], expire the tokens monthly in
order to maintain the security of the system16. 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
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.
Page 34
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 issued17. 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.
4.1.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.
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).
Page 35
4.1.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.
4.1.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.
4.1.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
Page 36
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.
Page 37
4.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:
4.2.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.
4.2.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.
Page 38
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.
4.2.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.
Page 39
4.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.
Page 40
5
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.
5.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
Page 41
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 money18.
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.
5.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 for19, 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
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.
Page 42
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.
5.2.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 coin20, 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 authentication21 (the bank knows that it is talking to Alice (and not someone
else), and Alice knows that she is talking to the bank).
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.
Page 43
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 anyone22.
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 goods23.
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.
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.
Page 44
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.
5.2.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
Page 45
$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 choosing24 a serial
number for each one25, 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.
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 2 160 chance of Alice choosing the same
serial number as someone else.
Page 46
5. The bank signs the one remaining blinded money order, debits Alice’s account,
and sends the digital coin to Alice26.
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).
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.
Page 47
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 online 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.
5.2.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
Page 48
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 identity27.
2. Alice blinds the 100 money orders, and sends them to the bank.
27
This is because, in splitting the secret, Alice chooses a different random number for each
I1,I2,…,I10.
Page 49
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.
Page 50
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 string28. 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
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.
Page 51
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].
Page 52
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.
5.2.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.
Page 53
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.2.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
Page 54
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].
5.2.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.
5.2.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
Page 55
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
possible29.
It is already possible for Alice to create money orders for different amounts, and thus
to store coins of different amounts in her digital wallet30. 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 value31. 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.
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].
Page 56
5.2.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.
5.2.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 user32. 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).
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.
Page 57
5.2.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.
5.2.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.
Page 58
5.2.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.
Page 59
5.2.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
elsewhere33), 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.
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.
Page 60
5.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.
Page 61
6
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.
6.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
Page 62
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.
6.1.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.
Page 63
Required by
Acquirer
Requirement
1KP
2KP
3KP
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
acquirer34.
Proof that the consumer has
✓
authorised the transaction.
Consumer
Protection of credit card number
✓
✓
✓
✓
✓
✓
✓
✓
✓
Proof of merchant accreditation.
✓
✓
Receipt from merchant for goods.
✓
✓
from eavesdroppers and corrupt
merchants.
Proof that the acquirer has
authorised the transaction.
Anonymity from the merchant.
Impossibility of unauthorised
✓
transactions.
Table 6-1: iKP Security Levels
34
The acquirer could issue certificates to all accredited merchants, allowing Alice easily to check
whether a particular merchant is approved by the acquirer.
Page 64
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.
6.1.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 authentic35 she bundles her
credit card details together with a hash of the invoice, to form a payment36.
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.
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.
Page 65
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.
Alice
1: Invoice, and acquirer’s
certificate.
2: Payment encrypted
with acquirer’s public key.
4: Confirmation of
Carol
payment, signed by the
acquirer.
3: Details of 2, and hash
of Carol’s version of the
Acquirer
transaction.
Represents a digital signature on the information in the box.
Figure 6-1: 1KP Protocol
Page 66
6.1.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.
1: Invoice, acquirer’s
Alice
certificate, and Carol’s
certificate.
2: Payment encrypted
with acquirer’s public key.
4: Confirmation of
Carol
payment, signed by the
acquirer.
3: Details of 2, and hash of Carol’s
version of the transaction, signed
Acquirer
by Carol.
Represents a digital signature on the information in the box.
Figure 6-2: 2KP Protocol
Page 67
6.1.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.
1: Invoice, acquirer’s
Alice
certificate, and Carol’s
certificate.
2: Payment encrypted
with acquirer’s public key,
4: Confirmation of
Carol
signed by Alice.
payment, signed by the
acquirer.
3: Details of 2, and hash of Carol’s
version of the transaction, signed
Acquirer
by Carol.
Represents a digital signature on the information in the box.
Figure 6-3: 3KP Protocol
Page 68
6.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.
6.2.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.
Page 69
6.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.
6.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.
Page 70
7
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 system37 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.
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.
Page 71
7.1 Analysis of Requirements
We begin our analysis with a discussion of service transactions with a value less than
one Rand38. 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.
7.1.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 increases39, 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.
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.
Page 72
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.
7.1.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.
Page 73
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 restored40.
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.
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.
Page 74
7.1.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 peerto-peer transactions, micropayments and the ability for coins to expire at the end of
every year.
7.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.
7.2.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
Page 75
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.
7.2.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
Page 76
the card is encrypted using a session key, which is exchanged using a public-key
cryptosystem41.
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 access42. 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.
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.
Page 77
7.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.
7.3.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 spending43. 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 card44.
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.
Page 78
7.3.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.
7.3.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 coin45 (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
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.
Page 79
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 restricted46), and
when they are produced for redemption, the name of the merchant, and amount spent,
is entered into that particular student’s transaction database47.
7.3.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-topeer 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.
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.
Page 80
7.3.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.
7.3.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.
Page 81
7.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 system48. Some form of Electronic
Data Interchange (EDI) would need to be implemented between the bank’s central
server, and Rhodes University student fees49.
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).
Page 82
7.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.
Page 83
7.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 peerto-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.
Page 84
8
Conclusions and Future Research
8.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
Page 85
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.
8.1.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.
Page 86
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.
Page 87
8.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.
Page 88
References
[Anderson et al,
Anderson, Ross, Kuhn, Markus, Tamper Resistance – a
1996]
Cautionary Note, 1996.
[Beenz]
beenz, http://www.beenz.com/us/home.ihtml.
[Bortner, 1996]
Bortner, Mark, Cyberlaundering : Anonymous Digital Cash and
Money Laundering,
http://www.law.miami.edu/~froomkin/seminar/papers/bortner.htm,
1996.
[Brands, 1994]
Brands, Stefan, Electronic Cash on the Internet,
ftp://ftp.cwi.nl/pub/brands/e-cash.ps, October 1994.
[Chaum, 1993]
Chaum, David, Online Cash Checks, cypherpunks-list #6929,
http://ganges.cs.tcd.ie/mepeirce/Project/Chaum/ways.html, 1993.
[Clarke, 1996]
Clarke, Roger, Identification, Anonymity and Pseudonymity in
Consumer Transactions: A Vital Systems Design and Public
Policy Issue,
http://www.anu.edu.au/people/Roger.Clarke/DV/AnonPsPol.html,
October 1996.
[Flooz]
Flooz : Online gift currency sent by e-mail with a greeting card
for any occasion or holiday, http://www.flooz.com.
[Froomkin, 1996]
Froomkin, A. Michael, Flood Control on the Information Ocean:
Living With Anonymity, Digital Cash, and Distributed Databases,
http://www.law.miami.edu/~froomkin/articles/oceanno.htm, 1996.
[Grabbe, 1998a]
Grabbe, J. Orlin, Digital Cash and the Future of Money,
http://www.aci.net/kalliste/dcfutmo.htm, 1998.
Page 89
[Grabbe, 1998b]
Grabbe, J. Orlin, Concepts In Digital Cash,
http://www.aci.net/kalliste/digiprin.htm, 1998.
[Grabbe, 1998c]
Grabbe, J. Orlin, Internet Payment Schemes: Part 1,
http://www.aci.net/kalliste/intpay.htm, 1998.
[Grabbe, 1998d]
Grabbe, J. Orlin, Internet Payment Schemes: Part 3,
http://www.aci.net/kalliste/intpay3.htm, 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,
http://info.isoc.org/HMP/PAPER/136/html/paper.html, April
1995.
[McCullagh et al,
McCullagh, Adrian, Caelli, William, Non-Repudiation in the
2000]
Digital Environment,
http://firstmonday.org/issues/issue5_8/mccullagh/index.html, July
2000.
[Menezes et al,
Menezes, A., van Oorschot, P., Vanstone, S., Handbook of Applied
1996]
Cryptography, CRC Press,
http://www.cacr.math.uwaterloo.ca/hac/, 1996, Chapters 1, 8, pp.
2, 16, 26, 28, 31, 32, 294.
[Network
Network Associates, Inc., An Introduction to Cryptography,
Associates, 1999]
ftp://ftp.pgpi.org/pub/pgp/6.5/docs/english/IntroToCrypto.pdf,
1999, pp. 11, 16, 17, 19, 20, 30-33, 45.
[Orwell, 1967]
Orwell, George, Nineteen Eighty-Four, Penguin Books, 1967.
Page 90
[Peirce et al,
Peirce, Michael, O'Mahony, Donal, Scalable, Secure Cash
1995]
Payment for WWW Resources with the PayMe Protocol Set,
http://www.w3.org/Conferences/WWW4/Papers/228/, 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,
Rivest, Ronald L., Shamir, Adi, PayWord and MicroMint: Two
1998]
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.
Page 91
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, http://www.cdt.org/crypto/risks98/, 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, ftp://rtfm.mit.edu/pub/news.answers/cryptography-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,
http://www.counterpane.com/whycrypto.html, 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.
Page 92
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,
http://www.anu.edu.au/people/Roger.Clarke/EC/Mondex.html, 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
ftp://ftp.cwi.nl/pub/brands/.
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,
http://www.anu.edu.au/people/Roger.Clarke/EC/ECDefns.html, February 1999.
Definitions and explanations of some terms in electronic commerce, such as
electronic publishing and electronic services delivery.
Page 93
Clarke, Roger, Net-Based Payment Schemes,
http://www.anu.edu.au/people/Roger.Clarke/EC/EPMEPM.html, 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,
http://www.anu.edu.au/people/Roger.Clarke/EC/Quantum.html, 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,
http://www.anu.edu.au/people/Roger.Clarke/EC/SETOview.html, 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.
Page 94
Economic Issues
Bernkopf, Mark, Electronic Cash And Monetary Policy,
http://www.firstmonday.org/issues/issue1/ecash/index.html, 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,
http://www.anu.edu.au/people/Roger.Clarke/EC/CFP97.html, 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,
http://www.anu.edu.au/people/Roger.Clarke/EC/WillPay.html, 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.
Page 95
De Long, J. Bradford, Froomkin, A. Michael, The Next Economy?,
http://www.law.miami.edu/~froomkin/articles/newecon.htm, 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,
http://www.clev.frb.org/research/workpaper/1998/Wp9822.pdf, 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 ?,
http://www.sfasu.edu/finance/fincash.htm, 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’.
Page 96
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,
http://www.firstmonday.org/issues/issue2_10/muscovitch/index.html, 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,
http://www.firstmonday.dk/issues/issue2/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.
Page 97
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,
http://www.law.miami.edu/~froomkin/articles/cfp97.htm, 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, http://www.aci.net/kalliste/money1.htm
& http://www.aci.net/kalliste/money2.htm, 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,
http://www.aci.net/kalliste/dcreg.htm, 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.
Page 98
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, http://www.jya.com/paperF1.htm,
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, http://www-users.informatik.rwthaachen.de/~senderek/certify/secret-key.protection.html, 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).
Page 99
Simpson, S., PGP DH vs. RSA FAQ, http://www.scramdisk.clara.net/pgpfaq.html,
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, http://ganges.cs.tcd.ie/mepeirce/Project/Chaum/cardcom.html, 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,
http://www.anu.edu.au/people/Roger.Clarke/DV/HumanID.html, 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, http://www.anu.edu.au/people/Roger.Clarke/DV/ACFF.html, 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.
Page 100
Clarke, Roger, The Digital Persona and its Application to Data Surveillance,
http://www.anu.edu.au/people/Roger.Clarke/DV/DigPersona.html, 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,
http://www.anu.edu.au/people/Roger.Clarke/DV/Trails.html, 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, http://www.law.miami.edu/~froomkin/articles/trustedno.htm, 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,
http://www.law.miami.edu/~froomkin/articles/arbitr.htm, 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
Page 101
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?,
http://www.firstmonday.org/issues/issue5_7/hove/index.html, 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.
Page 102
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.
Page 103
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
A mathematical function used to encrypt plaintext and
algorithm
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.
Page 104
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
Digital tokens are just a series of bits, and can thus be
problem
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
An electronic payment mechanism used to transfer funds
Transfer
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.
Page 105
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
A family of on-line payment protocols developed by IBM
Payments
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
An impersonation attack on public-key cryptography,
attack
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.
Page 106
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
An electronic money scheme where the merchant can
money
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.
Page 107
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
A widely available and accessible certificate system used
infrastructure
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 that uses a public-key algorithm.
cryptography
Page 108
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
A standard developed by MasterCard and VISA to handle
Transaction
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.
Page 109
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.
Page 110
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
Page 111
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
Page 112