臺灣靜宜大學電子商務碩士dissertation，數字權利限制問題的靈活分割方案，Elsevier Editorial System(tm) forElectronic Commerce Research and Applications
Manuscript Draft
Manuscript Number: ECRA-D-07-00019
Title: Digital Right Schemes for Limited Issue and Flexible Division
Article Type: Research Paper
Section/Category:
Keywords: Digital right, limited issue, flexible division, PKI
Corresponding Author: Associate Prof. Chia-Chen Lin, Ph.D.
Corresponding Author's Institution:Providence University
First Author: Chia-Chen Lin, Ph.D.
Order of Authors: Chia-Chen Lin, Ph.D.; Chia-Chi Wu, Ph. D. student; Chin-Chen Chang, Ph. D.
Manuscript Region of Origin:
Abstract: Digital right can be applied to various e-commerce applications, such as coupons, tickets and ecash.
The existing digital right schemes only help the issuer to issue digital rights without quantity limitation.However, issuer needs to limit the quantity of his digital rights due to marketing strategy.
In this paper, we propose a flexible digital right scheme, such that the issuer can easily control circulation ofeach broker. Furthermore, we propose one variant based on our first scheme to make a digital right that canbe flexibly divided according to owner's demand. The variant scheme conquers the weakness of paperbasedgift coupon, and makes the digital rights more flexible in redemption. Both schemes not only satisfythe confidentiality, anonymity, secure transference, preventing double spending and so on, but also expandthe applications of digital rights.
靜宜大學 資訊管理學系
Department of Computer Science and Information Management
Providence University
Dr. Norman M. Sadeh
Editor-in-Chief, Electronic Commerce Research and Applications
Feb. 23, 2007
Dear Sir:
I am sending you one file of my manuscript “Digital Right Schemes for Limited Issueand Flexible Division” submitted to the Electronic Commerce Research and Applications forpossible publication. This paper presents our original ideas, and it has not been submitted toother journals.
Your acknowledgment will be greatly appreciated.
Best Regards.
Sincerely,
Lin, Chia-Chen Ph. D.
Associate Professor
E-mail: [email protected]
Address: Department of Computer Science and Information Management
Providence University
Taichung, Taiwan 433, R.O.C.
Tel: 886-4-26328001 ext. 18108
FAX: 886-4-26324045
Cover letter
Digital Right Schemes for Limited Issue and#p#分頁標題#e#
Flexible Division
Chia-Chen Lin1, Chia-Chi Wu2 and Chin-Chen Chang2, 3
1Department of Computer Science and Information Management,
Providence University, Taichung 40724, Taiwan, R.O.C.
E-mail: [email protected]
2Department of Computer Science and Information Engineering,
National Chung Cheng University, Chiayi 621, Taiwan, R.O.C.
E-mail: [email protected]
3Department of Information Engineering and Computer Science,
Feng Chia University, Taichung 40724, Taiwan, R.O.C.
E-mail: [email protected]
Correspondence address:
Dr. Chia-Chen Lin
Department of Computer Science and Information Management,
Providence University,
Taichung 40724, Taiwan, R.O.C.
Email: [email protected]
TEL: 886-4-26328001 ext. 18108
FAX: 886-4-26321161
Manuscript
2
Digital Right Schemes for Limited Issue and Flexible Division
Abstract
Digital right can be applied to various e-commerce applications, such as coupons,tickets and e-cash. The existing digital right schemes only help the issuer to issuedigital rights without quantity limitation. However, issuer needs to limit the quantityof his digital rights due to marketing strategy.
In this paper, we propose a flexible digital right scheme, such that the issuer caneasily control circulation of each broker. Furthermore, we propose one variant based
on our first scheme to make a digital right that can be flexibly divided according toowner’s demand. The variant scheme conquers the weakness of paper-based giftcoupon, and makes the digital rights more flexible in redemption. Both schemes notonly satisfy the confidentiality, anonymity, secure transference, preventing doublespending and so on, but also expand the applications of digital rights.
Keywords: Digital right, limited issue, flexible division, PKI
3
1. Introduction
In the past years, many scholars have dedicated to study various electronicpayment systems. Certainly, current electronic payment systems can support varioususeful functions. Take digital cash for instance, it makes sure the owner is untraceable,and it is physically independent, transferable, divisible, off-line capable, and machineunderstandable.
However, digital cash still has its limitations. For example, thedigital cash cannot be specified for particular applications or special goods. Hence,
“digital ticket” concept was proposed for widespread use. In general, a digital ticket isa certificate that guarantees certain rights of the ticket owner. We can say the digitalcash and micro-payment are special applications of digital ticket.Some digital tickets, e.g, E-gold [14] and E-Stamp [6], have already beendeveloped. In 1998, Fujimura and Nakajima defined a digital ticket as comprisingissuer, promise and owner [8]. Based on above definitions, they clarified therequirements of general-purpose digital ticket and its four unique properties, which arenot required for digital cash. They are (1) machine-understandability of ticket contents,#p#分頁標題#e#
(2) state-transitionality of ticket status, (3) composability of multiple tickets, and (4)parameterization of ticket features on untraceability, transferability and divisibility.
In addition, they used thirteen properties to compare digital cash with digital ticket.
The comparison results are listed in Table 1 as follows.
Table 1. The comparisons between digital cash and digital ticket [8]
Properties Digital cash Digital ticket
(1) Secure Yes Yes
(2) Anonymous Yes Traceable/Untraceable
(3) Physical independence Yes Yes
(4) Transferable Yes Transferable/ Not transferable
4
(5) Divisible Yes Only once/ Specified times/
Infinite times
(6) Off-line capable Yes Yes
(7) Persistent Yes Persistent/ Specified period
(8) Machine-understandable No Yes
(9) State manageable No Yes
(10) Composable No Yes
(11) Wide acceptability Yes Yes
(12) User friendly Yes Yes
(13) Monetary freedom Yes No
In 1999, Fujimura et al. developed a comprehensive digital ticket circulation modelshown in Figure 1 [9]. In Fujimura et al.’s model, there are six entities: CA, issuer,service provider, user, broker and shop. An issuer is in charge of creating, signing,issuing a digital ticket and authorizing brokers to sell digital ticket; a user redeems theticket; and a service provider fulfills the service expressed by the ticket. A broker sellsdigital tickets to users. They also defined three types of ticket transactions: (1)issuance: is an action in which issuer grants ownership of tickets to users, (2) transfer: isan action in which a user transfers ownership of ticket to the other user, and (3)redemption: is an action in which a user redeems the rights expressed by ticket toservice provider.
5
Figure 1. Ticket circulation model [8]
Later, Fujimura discovered a conventional wallet usually contains many entities,such as cash, credit card, membership card, gift certificate, coupon, admission ticket,loyalty point, plane ticket, and so on, but only the three former ones have beendigitalized. Therefore, he defined “Digital Right (DR)” as a digital representation ofthe right to claim the service and goods, which can be issued by different issues,presents various types of rights, and may be invalidate when it is redeemed ortransferred. A digital right defined by Fujimura contains four elements, includingissuer, promise, owner and validity-condition. Using the digital right concept, hebelieved the rest entities of a wallet can be digitalized in the future. To provide acommon infrastructure, which can assist any party to issue various digital rights andsupport consumers to use and transfer their digital rights; Fujimura further proposed aDigital Right Trading Infrastructure (DRTI) [10]. In Fujimura’s DRTI, four parties areinvolved, including an on-line ownership management system (OOMS), issuer, user andservice provider.In 2003, Fujimura and Eastlake extended their discussion to crediting loyalty#p#分頁標題#e#
points and collecting digital coupons or gift certificates [12]. They used the “voucher”
Network
Issuer CA Service
Provider
Service
Provider
Shop
User
Broker User
CARD
Issue(wholesale)
Transfer(sale)
Transfer Transfer
Redeem
(Consume/Present)
6
concept to represent above activities. They also designed a voucher trading system.
Certainly, after Fujimura clarified the definitions of digital ticket and digital right, it is
obvious that the digital right can represent more complex services or rights than the
digital ticket does. In the following sections, we will discuss digital rights instead of
digital ticket. Based on our observation, most of the current digital ticket circulation
models and trading systems focus on how to apply digital right concept to different
applications and design diverse models, frameworks or systems to help the issuer to
issue various types of digital rights, and to support consumers to transfer or redeem their
digital rights. Few of them further enhance digital right’s function to solve the
potential problems caused by digitalization of the paper-based ticket or right, or to solve
the paper-based ticket or right’s weakness. Two examples are demonstrated as follows
to declare our opinions. The first one is an issuer usually issues limited coupons to
promote his products. Once an issuer authorizes his brokers to distribute or sell his
coupons. Issuers have to print out paper-based coupons and deliver coupons to brokers.
Therefore, it is easy to prevent brokers from over-selling coupons. However, it is
difficult to prevent brokers from over-selling e-coupons because duplication is quite
easy and costless. The other one is current paper-based gift coupon is fixed value. If
a consumer uses a coupon to buy a good that is less than the value of the coupon, he
may suffer a loss because shop will not return him the price difference. The former
one describes the potential problem of digital ticket/ right, and the latter one presents the
weakness of traditional paper-based gift coupon. To conquer above problems and to
enhance the function of existing digital right, we apply cryptographic techniques to
propose two flexible digital right schemes in this paper, one for limited issue and the
other for flexible division.
The rest of this paper is organized as follows. In Section 2, we shall briefly
review Matsuyama and Fujimura’s rights trading system [15]. Our proposed flexible
7
digital right schemes are presented in Section 3. Then, the security analyses are shown
in Section 4. Finally, we draw some conclusions in Section 5.
2. A Review of Matsuyama and Fujimura’s Rights Trading System
In this section, we shall briefly review Matsuyama and Fujimura’s rights trading#p#分頁標題#e#
system [15]. Basically, they proposed the ticket-token management protocols to solve
digital ticket transfer problem. In their system, there are four entities: issuer, user,
ticket-token manager and service provider involved. Their protocols can be divided
into three transactions: issuance transaction, transference transaction and redemption
transaction. The detailed descriptions are given as follows.
Issuance transaction
Issuance transaction comprises seven steps as follows.
Step 1. User U0 sends his request and payment to the issuer.
Step 2. The issuer sends his certificate to user U0.
Step 3. User U0 sends his certificate to the issuer.
Step 4. The issuer sends a ticket T to user U0.
Step 5. User U0 generates a new ticket key K0 and computes an issue request R0 =(h(T),
h(K0)), where h( ) is a one-way hash function, and then sends R0 back to the
issuer.
Step 6. The issuer generates the ownership information IO0=(h(T), nil, h(K0)) first.
Next, he registers IO0 with the ticket-token manager, where K0 is the ticket-token
for T.
Step 7. The ticket-token manager makes IO0 public. Hence, user U0 can evaluate the
ownership by verifying IO0 using K0.
Transference transaction
Assume user U0 wants to transfer T to U1, four steps of transference transaction will be
8
performed as follows.
Step 1. User U0 sends T to user U1.
Step 2. User U1 generates a new ticket-token K1, and creates a transfer request R1=(h(T),
h(K1)). At last, user U0 sends R1 back to U0.
Step 3. User U0 generates a new ownership information IO1=(h(T), K0, h(K1)) and sends
IO1 to the ticket-token manager.
Step 4. The ticket-token manager compares h(K0) in IO0 with the hashed value of K0 in
IO1. If they are equal, the ticket-token manager replaces the ticket-token K0
with K1.
Redemption transaction
If user Un wants to fulfill his ticket, three steps will be conducted as follows.
Step 1. User Un presents his ticket T and ticket-token Kn to the service provider.
Step 2. The service provider presents the ownership information IOn+1=(h(T), Kn, nil) to
the ticket-token manager.
Step 3. The ticket-token manager checks whether h(Kn) in IOn is equal to the hash value
of Kn in IOn+1 given by user Un. If they are equal, the ticket-token manager
deletes all information on ticket T and notifies the service provider that the
ownership information is valid. Otherwise, the ticket-token manager will
notify the service provider to reject user’s redemption.
Matsuyama and Fujimura applied ticket-token to implement transference transaction
and verification of the digital ticket ownership [15]. Their idea is simple and their
implementation is easy; however, their system does not satisfy the divisible requirement.
That means if an issuer adopts Matsuyama and Fujimura’s system to implement an#p#分頁標題#e#
e-coupon (e.g., gift coupon) circulation environment, consumers may suffer a loss when
what they buy is of less value than the e-coupon’s value. In addition, their system
9
neither supports the complex digital ticket circulation model nor discusses the brokers’
overissue problem.
To support two additional requirements: limited issue and flexible division, we
propose our proposed digital right scheme for limited issue in Subsection 3.3. In
Subsection 3.4, we will propose one variant with flexible division property based on our
digital right scheme presented in Subsection 3.3. The detailed descriptions of our
proposed digital right schemes will be presented in the following section.
3. The Proposed Flexible Digital Right Schemes
Although many scholars treat digital right and digital ticket as the same thing, their
functions are not exactly the same. According to Fujimura’s definitions [10], digital
ticket only contains three items: issuer, promise, owner; but digital right consists of four
elements: issuer, promise, owner, and validity-condition. Since digital right can
represent more complex services than digital ticket does, we shall adopt digital right in
our digital rights trading model, and then we further propose our digital right schemes
based on the model shown in Figure 2.
Figure 2. Our proposed digital rights trading model
Issuer/service provider
1
1 1 1
U1 U2 ⋅⋅⋅Um
2
2 2 2
1 2 m U U ⋅⋅⋅U 1 2 n
n n n
m U U ⋅⋅⋅U
Issued
Database
Sale
Database 2
Sale
Database 1
Sale
Database n
B1 B2 ... Bn
: Issuing DRT
: Purchasing DR
B: Broker, U: User : Redeeming DR
10
In our digital rights trading model, there are only three parties involved: users,
service provider and brokers, because the service provider also serves as an issuer in our
schemes. In Figure 2, Bx denotes the broker and i
j U denotes the user Uj registered at
the broker Bi. Three databases are included in our proposed digital rights trading
model. The service provider is responsible for issued database, and the broker is in
charge of the sale database. Issued database contains Issued_DRT table, which stores
DRTs issued by the issuer. Issued_DRT table is composed of six fields: (1) the identity
of the broker IDB, (2) digital right template DRT, (3) the initial serial number of DR that
is issued by the issuer SN_Start, (4) the initial serial number of DR that is issued by the
issuer SN_End, (5) the issue date Issue_Date, and (6) the last issued serial number SN.
Sale Database is maintained by the broker and records the sold DR’s information.
Basically, sale database is composed of three tables: Customer table, Sale table and DRT#p#分頁標題#e#
table, shown in Figure 3.
DRT Table:
Sale Table:
Customer Table:
Figure 3. Sale Database’s Data Items
In Figure 3, Sale_Date is the sale date. IDU is the identity of the user. CertU is the
certificate of customer. kij is the shared key between user Ui and broker Bj after Ui
registered at Bj.
Moreover, each proposed digital right scheme consists of five phases: initialization,
issuance, purchasing, redemption and transference phases. In our schemes, we assume
that Public Key Infrastructure (PKI) has existed in the network already; each entity has
her/his owner public and private key pair and certificate. Our first scheme is designed
to conquer the broker’s overissue problem. The second scheme is the variant of our
SN IDU DR Sale_Date
IDSP DRT SN_Start SN_End Issue_Date
IDU CertU kij
11
first one to achieve flexible division property. Both of them are based on our proposed
digital rights trading model. Therefore, in the following subsections, we first explain
our notations in Subsection 3.1. Next, we describe the components of our digital rights
in Subsection 3.2. In Subsection 3.3, we shall introduce our first digital right scheme.
In the Subsection 3.4, the variant one based on our first scheme is presented.
3.1 The Notations
For convenience, we list the notations in the following.
Ui: The user i.
Bj: The broker j.
ISk: The issuer k.
IDIS: The identity of the issuer/service provider.
IDB: The identity of the broker.
IDU: The identity of the user.
Certx: Certificate of x entity.
kij: The shared key between user Ui and broker Bj after Ui registered at Bj.
SN: Serial number.
SN_Start: The initial serial number of DR that is issued by the issuer.
SN_End: The end serial number of DR that is issued by the issuer.
α, β: Two large random numbers.
Curr_Date: Current date.
Issue_Date: Issued date.
Sale_Date: Sale date.
Expi_Date: Expiration date.
Valid_Period: The valid period that is equal to the difference between Expi_Date and
Sale_Date.
12
Sale_Amount: The limited amount of DR that is determined by the issuer.
Signx(m): Using x’s private key to sign the message m.
Hx(m): Applying the one-way hash function H() x times to message m.
Ek(m): Using the key k to encrypt the message m.
DRT: Digital right template, which is issued by the issuer. The DRT defines the issuer,
promise and validity conditions of the digital right. Each DRT contains an issuer’s
signature to prove its validity.
3.2 Components of Our Digital Right
In our proposed schemes, each service provider has to determine how many
services he would like to provide first. Then, the issuer designs his digital right
template (DRT) for each service. Each DRT contains four components, including IDIS,#p#分頁標題#e#
Pi, Vi, SignIS(H(IDIS, Pi, Vi)). P denotes promise, which is promise or services
guaranteed by the issuer IS. V denotes the validity conditions defined by the issuer for
each service or promise. For example, if McDonald wants to generate one kind of
e-coupon to allow his customers to buy one drink with a fifty percent discount during a
specific period, e.g., January 2005. McDonald has to generate a DRT first. In the
DRT, McDonald is the issuer and is the service provider, so IDIS is McDonald’s
identification. P indicates fifty percent discount for each drink, and V indicates January
2005.
After generating DRTs for different services, the issuer further authorizes some
brokers to generate their digital rights (DRs) according to issuer’ DRTs. The
authorized brokers will sell DRs to customers later. Basically, a DR contains five
components: digital right’s serial number SN, digital right template DRT, customer’s
purchase date Sale_Date, the digital right’s expiration date Expi_Date, and a hash value
HValid_Period (α). DR does not contain any information related to its owner. Only DRO
13
represents the ownership of a digital right. Therefore, when a customer purchases a
digital right, the broker has to use his secret key to generate a DRO
SignBj(H(DR,H(IDUi))) for the customer. Only legal owner of a digital right can
present a valid DRO. In our proposed schemes, the customer has to present his DRO
and DR together to prove his ownership of his digital right when he wants to redeem or
transfer his digital right.
3.3 The Proposed Digital Right Scheme with Limited Issue Property
In this subsection, we present the proposed scheme with limited issue property.
The proposed scheme is divided five phases: initialization, issuance, purchasing,
transference and redemption. In our proposed scheme, users purchase their digital
rights first. Then, they can decide to transfer their digital rights to others or redeem
their digital rights for specific services or goods. Each DR is only allowed to be
redeemed once. The details of five phases are described in the following.
Initialization Phase
In this phase, issuers define their digital right templates DRTs, and record them in
their Issued databases. Brokers record their authorized DRTs in their DRT tables.
User Ui takes the following steps to register at the broker Bj before he wants to buy
digital rights.
Step 1. User Ui generates a session key Key first. Next, user Ui encrypts his identity,
Key and certificate Certi using brker Bj’s public key. At last, he sends them to
broker Bj for registration.
Step 2. After Bj receives above message, Bj decrypts it using his private key first. Then,
Bj verifies user’s Certi, and checks whether Ui exists in his Customer Table using
user’s Certi. If he is not being, Bj generates a unique IDUi and a shared key kij.#p#分頁標題#e#
14
Then, he encrypts IDUi and kij using the session key Key. Finally, Bj sends
encrypted data to Ui; and stores IDUi, Certi, kij in his Customer Table.
Otherwise, Bj will inform user Ui that he is already registered.
Step 3. After receiving above message, Ui decrypts it first. Next, he stores (IDUi, kij) in
his smart card.
Issuance Phase
In this phase, the broker sends a request to an issuer for being an agency for selling
digital rights. If the issuer authorizes a broker to be his agency, he has to decide the
issue quantity of the authorized digital rights. In other words, the issuer has to
determine how many digital rights will be sold by the authorized broker. This phase
can de divided into four steps. All messages transmitted in the following steps are
encrypted by the receiver’s public key to achieve data confidentiality.
Step 1. Broker Bj sends his IDB and request to the issuer ISk for being an agency to sell
the digital rights of DRTi.
Step 2. Issuer ISk determines that Bj can sell n units of DRs, then ISk generates SN_Start
and SN_End which contains n serial numbers for broker Bj .
Step 3. Issuer ISk sends DRTi:{IDIS, Pi, Vi, SignIS(H(IDIS, Pi, Vi,))} and (SN_Start,
SN_End) to Bj. Meanwhile, IS stores {IDBj, DRTi, SN_Start, SN_End,
Issue_Date} in his Issue_DRT Table for later tracing.
Step 4. After receiving the above messages, broker Bj stores them into his DRT Table
and sends an acknowledgement to issuer ISk.
Purchasing Phase
In this phase, the registered users purchase digital rights DRs from broker Bj and
verify DRs’ validity. This phase can be broken down into six steps as follows. We
15
briefly illustrate them in Figure 4.
1. IDUi,Request
3. DR,H(α) 2. Generate DR, DRO and H(α)
4. Verify DR
and send
payment if
DR is valid
4. payment
5. Verify payment and store DR,
DRO if payment is valid
6. Compare
DR and DRO
5. DR, DRO, IDBj
Figure 4. Protocol for purchasing DRs
Step 1. User Ui determines which DRT he wants to buy. Next, user Ui sends his IDUi
and request to broker Bj.
Step 2. Broker Bj generates a new SN and checks the DRT Table to see whether SN is
less than or equal to SN_End. If SN is larger than SN_End, Bj has to reject Ui’s
request. Broker Bj generates a random number α. Then, Bj generates DR and
DRO pair according to the user Ui’s choice:
DR:{SN,DRTi, Sale_Date, Expi_Date, HValid_Period (α)},
DRO:{SignBj(H(DR,H(IDUi)))}.
Step 3. Broker Bj sends DR and H(α) to user Ui.
Step 4. User Ui checks DR to see whether it meets his request or not. If it does, user Ui
sends payment instrument to broker Bj.
Step 5. After receiving user’s payment, broker Bj verifies its validity. If it is valid,#p#分頁標題#e#
broker Bj sends DRO to user Ui. Meanwhile, broker Bj records (SN, IDUi, DR,
Sale_Date) in his Sale Table and sends (DR, DRO, IDBj) to Ui.
Step 6. After receiving the above messages, user Ui computes H(DR,H(IDUi)) and
compares it with decrypted DRO to verify the integrity of his DR. If they are
equal, he stores (H(α), DR, DRO, IDBj) into his smart card for later redemption.
16
Redemption phase
In this phase, the user Ui wants to redeem his DRs to the issuer IS for getting
services or goods. Before accepting user’s DR, issuer ISk checks whether the user is a
legal owner of DR. Next, issuer ISk checks SN to make sure the DR is not double
spending. Five steps will be conducted as follows. We demonstrate them in Figure 5.
IS
2. Checks the validity of DR
3.Checks SN
3. SN, DRO
4. acknowledgement: invalid or
(DR, DRO,HCurr_Date-Sale_Date (α))
5. DR, DRO,HCurr_Date-Sale_Date (α)
1.DR, DRO, H(IDUi),
HCurr_Date-Sale_Date(α), and IDBj
Bj Ui
Figure. 5 Protocol for redemption
Step 1. User Ui sends [DR, DRO, H(IDUi), HCurr_Date-Sale_Date(α), IDBj] to issuer ISk to get
the related goods or services.
Step 2. After receiving the above message, issuer ISk decrypts DRO using broker Bj’s
public key first. Next, issuer ISk computes H(DR, H(IDUi)) using DR and
H(IDUi) provided by user Ui and compares with decrypted DRO. If they are
equal, the digital right’s ownership is confirmed. Finally, issuer ISk calculates
HExpi_Date -Curr_Date(HCurr_Date-Sale_Date(α)), and checks whether it is equal to
HValid_Period(α) or not. If they are equal, that means the digital right is not
expired.
Step 3. Issuer ISk checks whether SN of DR is between SN_Start and SN_End in the
17
Issu_DRT Table through indexing by IDBj. If it holds, IS sends {SN, DRO} to
broker Bj to perform on-line verification for double spending.
Step 4. Broker Bj retrieves the record of Sale Table according to his received SN first.
Next, broker Bj verifies the validity of his received DRO. If it is valid, Bj
marks this record in the Sale Table to note that SN has been redeemed and
updates the status of DR as (DR, DRO, HCurr_Date-Sale_Date(α)). Finally, Bj sends
the last status of DR to issuer ISk. Otherwise, Bj notifies IS that DR is invalid.
Step 5. If broker’s acknowledgement is positive, issuer ISk provides user Ui goods or
services and returns the recipient, SignIS(H(DR, HCurr_Date-Sale_Date(α)), to user Ui.
Otherwise, issuer ISk rejects user’s request.
Transference transaction
Assume Ui and Uk are registered users. If user Ui wants to transfer his DR to user Uk,
eight steps will be performed as follows. The protocol for transference transaction is
shown in Figure 6.
2. IDBj, IDUi, DR, HCurr_Date-Sale_Date(α)#p#分頁標題#e#
6. Generate a new DR', DRO',H(α')
3. Check the expiration date
of DR
8. Store DR', DRO',H(α')
Uk
5. IDUi, DR, HCurr_Date-Sale_Date (H(DRO,H(IDUi||kij)), IDUk]
α')
1. Transference request
Bj Ui
3. Payment instruction
4. H(DRO,H(IDUi||kij))
α),
7. DR', DRO',H(Figure 6. Protocol for transference transaction
18
Step 1. User Uk sends a digital right transference request to user Ui.
Step 2. User Ui sends [IDBj, IDUi, DR, HCurr_Date-Sale_Date(α)] to user Uk.
Step 3. User Uk computes HExpi_Date -Curr_Date(HCurr_Date-Sale_Date(α)), and checks whether
the result is equal to HValid_Period(α) of DR or not. If it is valid, user Uk sends a
payment instruction to user Ui.
Step 4. If the payment instruction is correct, user Ui sends [H(DRO,H(IDUi||kij))] to user
Uk. Otherwise, the transaction is terminated.
Step 5. User Uk sends [IDBj,IDUi, DR, HCurr_Date-Sale_Date (α), H(DRO,H(IDUi||kij)), IDUk]
to broker Bj.
Step 6. After receiving the above messages, broker Bj performs the following substeps.
Step 6.1 Broker Bj rertieves data from Sale Table according to his received SN
and computes λ={SignBj(H(DR,H(IDUi)))}. Next, he retrieves the
(IDUi, kij) from his Customer Table by indexing IDUi to compute H(λ,
H(IDUi||kij)). Broker Bj compares it with his received
H(DRO,H(IDUi||kij)). If they are equal, the DR and identity of Ui are
verified.
Step 6.2 Broker Bj computes HExpi_Date-Curr_Date(HCurr_Date-Sale_Date(α)) and
compares it with HValid_Period(α). If they are equal, broker Bj marks the
record of Sale Table to note that it is transferred.
Step 6.3 Broker Bj generates new DR , DRO′ and a new random number α′ for
user Uk as follows:
Sale_Date′=Curr_Date, and Valid_Period′=Expi_Date-Curr_Date.
DR′:{SN, DRTi, Sale_Date′, Expi_Date, HValid_Period′ (α′)},
DRO′:{SignBj(H(DR′,H(IDUk)))}.
Step 7. Broker Bj stores (SN, IDUk, DR′, Sale_Date′) into Sale Table and sends (DR′,
DRO′,H(α′)) to user Uk.
19
Step 8. After receiving the above messages, user Uk computes H(DR,H(IDUk)) and
compares it with decrypted DRO to verify the integrity of his DR. If they are
equal, he stores (DR′, DRO′, H(α′), IDBj) in his smart card for later redemption.
In our proposed scheme, the issuer determines the issue quantities of his digital
rights for his authorized brokers. Each broker assigns a unique serial number for his
issued digital rights. In other words, each digital right contains a unique serial number,
which can be checked by the issuer during the redemption phase. Brokers can not
overissue digital rights without being discovered by the issuers. Therefore, our#p#分頁標題#e#
proposed scheme can help issuers to issue limited digital rights. Moreover, the fields
related to limited issue are optional. The steps related to checking the issued number
are also optional. The issuer can only record Start_SN and End_SN in his issued
database for his DRT with limited issue. That means our proposed scheme also can
support issuers to issue digital rights without limited quantity.
3.4 The Proposed Digital Right Scheme with Flexible Division Property
Although our proposed scheme presented in Subsection 3.3 can help the issuer to
issue limited digital rights, it could be damage user’s interest when it is applied to issue
e-gift coupons, because our proposed scheme does not have the flexible division
property.
In the existing paper-based gift coupon systems, if the good’s price is less than the
value of gift coupon, users have two choices. One is that users try to buy more goods
and make sure the total price is equal to the value of gift coupon. The other one is that
users pay for goods by using their gift coupons and their interests are damaged. To
conquer the weakness of paper-based gift coupon, we try to extend our proposed
scheme to achieve the flexible division and limited issue properties simultaneously.
In the variant scheme, we assume each DR has a fixed value. The structure of
20
digital right DR is modified as DR:{SN, DRTi, Sale_Date, Expi_Date, H Valid_Period (α),
HDR_Value(β)}. DR_Value is the fixed value of each DR. In addition, the Sale Table
maintained by the broker is modified to provide flexible division function, shown in
Figure 7. The balance equals DR_Value minus Pay_Value, where Pay_Value is the
value paid by the user for some services or goods.
Sale Table
Figure 7. The modified SaleTable
Our variant scheme also consists of initialization, issuance, purchasing, and
redemption phases. It also can support users to transfer their digital rights. Basically,
the initialization phase and issuance phase are the same as our proposed scheme
presented in Subsection 3.3. In the following paragraphs, we shall introduce the rest
phases: purchasing phase, redemption phase and transference transaction of our variant
scheme.
Purchasing Phase
In general, users conduct the following steps to purchase digital rights from the
broker. The protocol for our variant’s purchasing phase is presented in Figure 8.
1. IDUi,Request
3. DR, H(α) and H(β ) 2. Generate DR, DRO, H(α) and H(β )
4. Verify DR
and send
payment if
DR is valid
4. Payment
5. DR, Balance,
DRO, IDBj
5. Verify payment and store DR,
DRO if payment is valid
6. Compare
DR and DRO
Figure 8. Protocol for our variant’s purchase phase
SN IDU DR Balance Sale_Date#p#分頁標題#e#
21
Step 1. User Ui determines which DRT he wants to buy and sends his request to broker
Bj.
Step 2. Broker Bj generates a new SN and checks the DRT Table to see whether SN is
less than or equal to SN_End or not. If SN is larger than SN_End, Bj has to
reject Ui’s request. Broker Bj generates two random numbers α and β. Then,
Bj generates DR and DRO according to the user Ui’s choice:
DR:{SN, DRTi, Sale_Date, Expi_Date, HValid_Period (α), HDR_Value(β)},
DRO:{SignBj(H(DR,H(IDUi)))}.
Step 3. Broker Bj sends DR, H(α) and H(β) to user Ui.
Step 4. User Ui checks DR to see whether it meets his request or not. If it does, user Ui
sends payment instrument to broker Bj.
Step 5. After receiving user’s payment, broker Bj verifies its validity. If it is valid,
broker Bj sends DRO to user Ui. Meanwhile, broker Bj records (SN, IDUi, DR,
Sale_Date) in his Sale Table and sets Balance as DR_Value. Finally, broker Bj
sends (DR, Balance, DRO, IDBj) to Ui.
Step 6. After receiving the above messages, user Ui computes H(DR,H(IDUi)) and
compares it with decrypted DRO to verify integrity of DR. If they are equal, he
stores (H(α), H(β), DR, Balance, DRO, IDBj) in his smart card for later
redemption.
Redemption Phase
In this phase, Ui redeems a part of DR value to issuer ISk. Issuer ISk notifies broker
Bj to check the Balance of user’s DR. If the Balance is enough, then issuer ISk will
permit user Ui’s redemption. Since our variant scheme can allow user to redeem a part
of his digital right DR, we assume user Ui wants to redeem Pay_Value and Pay_Value is
less than Balance of his DR. The Protocol of variant scheme’s redemption phase is
22
shown in Figure 9.
Step 1. User Ui sends {DR, DRO, H(IDUi), HCurr_Date-Sale_Date(α), HBalance(β),
HBalancee-Pay_Value(β), Pay_Value, IDBj} to issuer ISk for redemption Pay_Value
of his DR.
Step 2. After receiving the above message, issuer ISk performs the following substeps.
Step 2.1 Issuer ISk first computes H(DR, H(IDUi)) and compares it with the
decrypted DRO. If they are equal, the ownership of digital right is
confirmed.
Step 2.2 Issuer ISk checks HExpi_Date-Curr_Date(HCurr_Date-Sale_Date(α)) to see whether
it is equal to HValid_Period(α) or not. If they are equal, the digital right is
not expired.
Step 2.3 Issuer ISk uses his stored Balance to check HDR_Value-Balance(HBalance(β)) to
see whether it is equal to HDR_Value(β). If they are equal, the HBalance(β)
is correct.
Step 2.4 Issuer ISk checks HPay_Value(HBalance-Pay_Value(β)) to see whether it is equal
to HBalance(β). If they are equal, the Pay_Value is verified.
Step 3. Issuer ISk sends {SN, HBalance(β), HBalance-Pay_Value(β), Pay_Value} to broker Bj to#p#分頁標題#e#
perform on-line validation for double spending.
Step 4. After receiving the above messages, broker Bj performs the following substeps.
Step 4.1 Broker Bj retrieves Balance and HDR_Value(β) from his Sale Table by
indexing his received SN.
Step 4.2 Broker Bj uses his received HBalance(β) to compute
HDR_Value-Balance(HBalance(β)). If it is equal to HDR_Value(β) that is
retrieved from DR in Sale Table, the validity of HBalance(β) is
confirmed.
Step 4.3 Issuer ISk uses his received Pay_Value and HBalance-Pay_Value(β) to
23
compute HPay_Value(HBalance-Pay_Value(β)). If it is equal to HBalance(β) that
is derived from Step 4.2, broker Bj updates the Balance in Sale Table as
(Balance-Pay_Value). Otherwise, broker Bj rejects the transaction,
and notifies issuer ISk that the DR is invalid.
Step 5. If the notification is positive, issuer ISk provides goods or services for user Ui,
and sings [DR, HCurr_Date-Sale_Date(α), HBalance(β), HBalance-Pay_Value(β), Balance,
Pay_Value] as a receipt for user Ui.
Step 6. Issuer ISk sends receipt to user Ui.
Step 7. User Ui updates his Balance as (Balance-Pay_Value) in his smart card, and
keeps his receipts.
IS
2. Checks the integrity of
DR, Balance, Pay_Value
3. SN, HBalance(β), HBalance-
Pay_Value(β), Pay_Value
5. acknowledgement: invalid or
receipt
6. receipt
1 DR, DRO, H(IDUi), HCurr_Date-Sale_Date(α),
HBalance(β), HBalancee-Pay_Value(β), Pay_Value, IDBj
Bj Ui
4. Checks the validity of
Balance, Pay_Value
7. Update Balance and keep
receipt
Figure 9. Protocol for variant’s redemption phase
Transference Transaction
In general, the transference transaction of our variant scheme is similar to our
proposed scheme presented in Subsection 3.3. The major difference between them is
the buyer in the variant scheme not only checks the validity of DR but also has to check
the balance of DR. Assume user Ui wants to transfer his DR to user Uk. Both of them
are registered users. The transference transaction can be broken down into eight steps.
24
The protocol for variant scheme’s transference transaction is shown in Figure 10.
Step 1. User Uk sends a digital right transference request to user Ui.
Step 2. User Ui sends [IDBj, IDUi,DR, τ=HCurr_Date-Sale_Date (α), υ=HBalance(β), Balance] to
user Uk.
Step 3. User Uk checks HExpi_Date-Curr_Date(HCurr_Date-Sale_Date(α)) to see whether it is equal
to HValid_Period(α) of DR or not. If they are equal, DR is not expired and user Uk
sends a payment instruction to user Ui.
Step 4. If the payment instruction is correct, user Ui sends [H(DRO,H(IDUi||kij))] to user
Uk. Otherwise, the transaction is terminated.#p#分頁標題#e#
Step 5. User Uk sends [IDBj, IDUi,DR, τ=HCurr_Date-Sale_Date (α), υ=HBalance(β), Balance,
H(DRO,H(IDUi||kij)), IDUk] to broker Bj.
Step 6. After receiving the above messages, broker Bj performs the following substeps.
Step 6.1 Broker Bj retrieves data from his Sale Table according to SN and
computes μ={SignBj(H(DR,H(IDUi)))}. Next, he retrieves the (IDUi,
kij) from his Customer Table by indexing IDUi, computes H(μ,
H(IDUi||kij)) and compares it with his received H(DRO,H(IDUi||kij)). If
they are equal, DR and the identity of Ui is verified.
Step 6.2 Broker Bj computes HExpi_Date-Curr_Date(τ) and HDR_Value-Balance(υ) and
compares them with HValid_Period(α) and HDR_Value(β) of DR, respectively.
If they are all equal, broker Bj marks the record of Sale Table as
transferred.
Step 6.3 Broker Bj generates two random numbers α′, β′ and then generates new
DR′ and DRO′ for user Uk as follows:
Sale_Date′=Curr_Date, Valid_Period′=Expi_Date-Curr_Date.
DR′:{SN,DRTi, Sale_Date′, Expi_Date, H Valid_Period′ (α′), HDR_Value(β′)},
DRO′:{SignBj(H(DR′,H(IDUk)))}.
25
Step 7. Broker Bj stores (SN, IDUk, DR′, Balance, Sale_Date′) into his Sale Table and
sends (DR′, DRO′, Balance, H(α′), H(β′)) to user Uk.
Step 8. After receiving the above messages, user Uk computes H(DR′,H(IDUk)) and
compares it with decrypted DRO to verify the integrity of his DR. If they are
equal, he stores (H(α′), H(β′), DR′, Balance, DRO′, IDBj) (DR′, DRO′,H(α′) ,
IDBj) into his smart card for later redemption.
Uk
3. Check the expiration date of DR
7. DR’, DRO’, Balance, H(α’), H(β’)
2. τ 1. Transference request
Bj
Ui
6. Check the validity of DR,
Balance, Pay_Value
5. IDBj, IDUi,DR, τ , υ , Balance,
H(DRO,H(IDUi||kij))
3. Payment instruction
4. H(DRO,H(IDUi||kij))
8. Store DR’, DRO’, Balance, H(α’), H(β ’)
IDBj, IDUi,DR, , υ, Balance
Figure 10. Protocol for variant’s transference transaction
4. The Security Analysis
In this section, we are going to show that our proposed schemes are secure. First,
we discuss the security of our first scheme in Subsection 4.1. Then, we will analyze
the security of our variant scheme in Subsection 4.2. In security analyses, we
summarize security issues, such as confidentiality, anonymity, verifiability, preventing
forgery, preventing alternation, preventing duplicate-redemption, preventing
reproduction, non-repudiation and trust manageability, proposed by Fujimura and#p#分頁標題#e#
Nakajima [8], and Fujimura and Eastlake [12].
26
4.1 The Security of Our First Scheme
In the following, we are going to show how our first proposed scheme meets the
following security requirements.
1. Confidentiality:
In our proposed scheme, we assume PKI exists. Since each party can easily find out
others’ certificates and get their public keys, each transmission is performed through the
secure channel. Even in our initialization phase, the user can generate a symmetric
session key when he wants to register at the broker. Broker can use user’s session key to
encrypt data and sends them back. When registration is completed, the broker will get
user’s certificate. In other words, the broker can use user’s public key to encrypt
transmitted data later. Therefore, in our proposed scheme, the confidentiality is
guaranteed.
2. Anonymity:
In purchasing phase, the broker will generate a unique identity for each user. In
redemption phase, the user presents [DR, DRO, H(IDUi), HCurr_Date-Sale_Date(α), IDBj] to
the issuer. Issuer IS can compute H(DR, H(IDUi)) using his received data, and
compares it with that of DRO. If they are equal, the DR’s ownership is confirmed.
Since user only presents his identity in a hashed value, issuer can verify DR’s ownership
and he does not know who the owner is. User’s anonymity is achieved in our scheme.
3. Verifiability:
In our proposed scheme, there are three items, which need to be verified: DR, the
ownership of DR and DR’s expiration date. Since the broker will sign each digital
right DR, any party can use broker’s public key to verify DR’s validity. The verifiability
of DR’s ownership can be achieved by using the corresponding DRO, because DRO
consists of DR and hash value of user’s identity. Once a user presents his DR and the
hash value of his identity, the issuer and broker can easily verify the ownership of user’s
27
DR. The expiration date of DR also can be verified easily, because the user has to
present [DR, DRO, H(IDUi), HCurr_Date-Sale_Date(α), IDBj] to the issuer in the redemption
phase. Issuer just simply checks whether HExpi_Date-Curr_Date(HCurr_Date-Sale_Date(α)) is
equal to HValid_Period(α) or not. If they are not equal, it means DR is expired. In
transference transaction, buyers also can use the same way to check whether their DRs
are valid or not. To sum up, the verifiability is achieved in our proposed scheme.
4. Preventing forgery:
In our proposed scheme, the broker signs each DRO. Since DR is one component of
DRO, and only the broker has his private key, no one can forge DR or DRO without
being discovered.
5. Preventing alternation:
If user tries to alter the valid period of his digital right, or modify the promise of his#p#分頁標題#e#
digital right, he has to get the broker’s private key first. However, user has no chance
to get broker’s private key. That means user cannot alter his digital right without
compromising his digital right’s integrity and validity.
6. Preventing duplicate-redemption:
In the redemption phase, user has to present [DR, DRO, H(IDUi), HCurr_Date-Sale_Date(α),
IDBj] to the issuer. Issuer checks whether SN of DR is between the SN_Start and
SN_End in the Issu_DRT Table through indexing by IDBj. If SN of DR is valid, issuer
sends {SN, DRO} to broker Bj to perform one-line verification. Broker Bj further
checks his Sale Table according to {SN, DRO}. If SN exists in broker’s Sale Table and
is not marked, then DR can be redeemed for goods or services. Otherwise, the DR has
been spent and broker will inform issuer to reject user’s request. Since SN is unique in
each Sale Table, the double-redemption can be prevented.
7. Preventing reproduction:
In our proposed scheme, user has less intention to reproduce his DR and transfer the
28
reproduced DR to the other users, because he also has to provide his H(IDUi) to make
the reproduced DR can pass issuer’s verification in the redemption phase. However, it
may make user unable to redeem his DR and damage his own interests. Therefore, our
scheme can prevent reproduction indirectly. If a user redeems his DR first, and
transfers his reproduced DR to the other users later, the reproduced DR will be
discovered as duplicate-redemption in the redemption phase. Therefore, in our
proposed scheme, users can not reproduce their DRs without being discovered.
8. Non-repudiation:
In our proposed scheme, issuer signs his DRT, and broker signs the DROs. They can
not claim that they do not issue DRTs and DROs. In the transference phase, once user
Ui agrees to transfer his DR to user Uk, user Ui sends [IDBj, IDUi,DR, HCurr_Date-Sale_Date(α),
Balance, H(DRO,H(IDUi||kij))] to user Uk. Since the shared key kij is a secret shared
between user Ui and the broker for a DR. If user Uk can prevent a valid
H(DRO,H(IDUi||kij)), user Ui can not deny that he promises to transfer his DR to user Uk.
9. Trust manageability:
In the transference phase, the broker is in charge of the transference transaction and
checks transferred DR status for seller and buyer. If a dispute occurs, seller and buyer
can ask the broker to provide evidence. Therefore, our proposed scheme can achieve
trust manageability.
4.2 The Security of our variant scheme
The extension version inherits all properties from the proposed scheme presented
in Subsection 3.3. Therefore, it can satisfy all security requirements mentioned in
Subsection 4.1. The most dissimilar part between the first scheme and our variant
scheme is that the latter one can achieve flexible division property. In this section, we#p#分頁標題#e#
shall focus on the security issue related to the flexible division property of DR.
29
Basically, our variant scheme may suffer from some attacks as follows.
1. User Ui wants to modify Balance value of his digital right:
In the redemption phase, user has to present [DR, DRO, H(IDUi), HCurr_Date-Sale_Date(α),
HBalance(β), HBalancee-Pay_Value(β), Pay_Value, IDBj] to issuer. Issuer can retrieve
HDR_Value(β) from his received DR, computes HDR_Value-Balance(HBalance(β)), and checks
whether they are equal. If they are not equal, issuer will treat DR as invalid, and reject
user’s request. If user wants to pass issuer’s verification, he has to modify HDR_Value(β)
of DR. Since DRO contains the original DR, and DRO is signed by the broker. User
has no chance to modify his DR’s balance value and forge broker’s signature without
being discovered by the issuer.
2. Issuer may want to forge HBalance(β) in order to get more benefits.
For example, a user still has ten units of his digital right, but the issuer claims that the
user only has five units left. In this case, the user can present his receipt to broker Bj or
the judge and prove the issuer is cheating. Since the receipt is signed by the issuer in
the redemption phase, and the receipt contains H(DR, HCurr_Date-Sale_Date(α), HBalance(β),
HBalance-Pay_Value(β), Balance, and Pay_Value). By chaining each receipt, the broker can
find out which redemption transaction is incorrect and ask the issuer to correct it.
5. Conclusions
Although several digital right schemes have been proposed, rare schemes focus on
two practical issues. One is limited issue and the other is flexible division. In this
paper, we first develop a digital right scheme that helps an issuer to issue limited
quantity of his digital rights. Then, we extend our proposed scheme to achieve limited
issue and flexible division properties at the same time. All of them can satisfy
confidentiality, anonymity, verifiability, preventing forgery, preventing alternation,
preventing duplicate-redemption and related security requirements. In addition, digital
30
rights can be transferred fairly among users in both schemes.
Our schemes also can support issuer to issue digital right without limited quantity
by slight modification. In general, our schemes extend the applications of digital
rights. Nevertheless, our computation cost is high in both schemes due to adopt public
key system to achieve data confidentiality. In the future, we will try to reduce the
computation cost to apply our schemes to a mobile commerce environment.
References
1. F. Bao, “A Scheme of Digital Ticket for Personal Trusted Device,” Proceedings of
the 15th IEEE International Symposium on Personal, Indoor and Mobile Radio#p#分頁標題#e#
Communications (PIMRC 2004), Vol. 4, pp. 3065-3069, 2004.
2. D. Chaum, “Blind Signatures for Untraceable Payment,” Proceedings of Advanced
in Cryptology-CRYPTO’82, New York, pp. 199-203, 1983.
3. D. Chaum, A. Fiat, and M. Naor, “Untraceable Electronic Cash,” Proceedings of
Advanced in Cryptology-CRYPTO’88, LNCS 403, Springer-Verlag, pp. 319-327,
1989.
4. D. Chaum and S. Brands, “Minting Electronic Cash,” Spectrum, IEEE, Vol. 34,
Issue 2, pp. 30-34, Feb. 1997.
5. E-Stamp Corporation, “E-Stamp,” http://www.e-stamp.com/.
6. C. I. Fan, W. K. Chen and Y. S. Yeh, “Date Attachable Electronic Cash,” Computer
Communications, Vol. 23, Issue 4, pp. 425-428, Feb. 2000.
7. A. O. Freier, P. Karlton, and P. C. Kocher, “The SSL Protocol Version 3.0,” IETF
Internet Draft, 1996, http://wp.netscape.com/eng/ssl3/draft302.txt.
8. K. Fujimura and Y. Nakajima, “General-Purpose Digital Ticket Framework,”
Proceedings of the 3rd USENIX Workshop on Electronic Commerce, Boston,
Massachusetts, USA, pp. 177-186, Aug. 1998.
31
9. K. Fujimura, H. Kuno, M. Terada, K. Matsuyama, Y. Mizuno, and J. Sekine,
“Digital-Ticket-Controlled Digital Ticket Circulation,” Proceedings of the 8th
USENIX Security Symposium, Washington D.C., USA, pp. 229-238, Aug. 1999.
10. K. Fujimura, “Digital-Right Trading Infrastructure (DRTI),” Proceedings of the 46th
Internet Engineer Task Force (IETF), Washington D.C., USA, Nov. 1999,
http://www.ietf.org/proceedings/99nov/slides/trade-drti/index.htm.
11. K. Fujimura, M. Terada and J. Sekine, “A World Wide Supermarket Scheme Using
Rights Trading System,” Proceedings of 7th IEEE International Conference on
Parallel and Distributed Systems Workshops, pp.289- 294, Jul. 2000.
12. K. Fujimura and D. Eastlake, “Requirement and Design for Voucher Trading System
(VTS),” IETF Internet Draft, 2003, http://www.faqs.org/rfcs/rfc3506.html.
13. K. Fujimura and M. Terada, “XML Voucher: Generic Voucher Language,” IETF
Draft, 2005, http://www.ietf.org/internet-drafts/draft-ietf-trade-voucher -lang-07.txt.
14. Gold & Silver Reserve, Inc., “E-Gold,” http://www.e-gold.com/.
15. K. Matsuyama and K. Fujimura, “Distributed Digital-Ticket Management for Rights
電子商務碩士dissertationTrading System,” Proceedings of the 1st ACM Conference on Electronic Commerce,
pp.110-118, Nov. 1999.
16. T. Okamoto and K. Ohta, “Universal Electronic Cash,” Proceedings of the Advances
in Cryptology-Crypto’91, Springer-Verlag, pp.324-337, 1992.
17. R. Song and L. Korba, “How to Make E-cash with Non-repudiation and
Anonymity,” Proceedings of the International Conference on Information#p#分頁標題#e#
Technology: Coding and Computing (ITCC’04),Vol. 2, pp. 167 – 172, Las Vegas,
Nevada, USA, Apr. 2004.
18. M. Terada and K. Fujimura, “Voucher Trading System Application Programming
Interface (VTS-API),” IETF Internet Draft, 2004,
http://www.400190.com/dissertation_writing/Ecommerce/