Secure E-Commerce Protocol with Complex Trading Capabilities of
Intermediaries
C
˘
at
˘
alin V. B
ˆ
ırjoveanu
1
and Mirela B
ˆ
ırjoveanu
2
1
Department of Computer Science, “Al.I.Cuza” University of Ias¸i, Ias¸i, Romania
2
Vitesco Technologies, Ias¸i, Romania
Keywords:
Security Protocols, Formal Verification, Multi-Party E-Commerce, Complex Transactions, Strong Fairness.
Abstract:
Up to now, there are many multi-party fair exchange protocols with applications in buying physical/digital
goods, digital signature of contracts and certified e-mail, but there is no e-commerce protocol that allows
multiple intermediaries to perform aggregate, chained or optional transactions. In this paper, we propose the
first multi-party e-commerce complex transaction protocol that allows the customer to acquire some physical
products through many intermediaries and providers. Considering complex transactions rise new challenges
for assuring strong fairness, that are not appearing in two-party transactions. The objective of our proposal is to
ensure strong fairness, effectiveness, timeliness, non-repudiation and confidentiality in a multi-party scenario.
The formal verification of our proposal using Cl-AtSe model checker proves that all security requirements
mentioned above are satisfied.
1 INTRODUCTION
E-commerce is a widely used term that is an umbrella
which includes many types of commercial activities.
The security threats to e-commerce and the growing
losses they cause lead to the need of secure protocols
to protect from them.
In this paper, we propose a secure e-commerce
protocol with applications in supply chain, consider-
ing intermediaries with complex trading capabilities.
In our proposal, the customer plans to acquire some
physical products through many intermediaries and
providers. An intermediary is a party which to ful-
fill a buying request received from customer or an-
other intermediary, has the capability to perform a
chained, aggregate or optional transaction with other
intermediaries/providers. An intermediary is engaged
in a chained transaction if he receives a request for a
product, and to fulfill it, in his turn requests the prod-
uct from a provider or another intermediary. When an
intermediary wants to acquire an entire pack of prod-
ucts, he is engaged in an aggregate transaction. There
are situations in which the buying request can not be
fulfilled in terms of delivery time, quantity, etc. In
these cases, is useful for the party that requested the
product to be able to express more options for prod-
ucts with similar features, engaging in this way in an
optional transaction (only one product from the ex-
pressed options is acquired). The complex trading ca-
pabilities of the intermediaries lead to a new business
model in which a complex transaction is a composi-
tion of chained, aggregate and optional transactions.
Aggregate and optional transactions are very im-
portant for robust procurement strategy in supply
chain. Optional transactions are important because
they minimize the risk of relying on a single interme-
diary or provider, which can cause a disruption fol-
lowing a natural disaster or geopolitical events. Com-
panies that source from different providers create re-
silience in their procurement process. On the other
hand, aggregate transactions allow the companies not
to remain with temporary unnecessary stocks (parts
that they cannot use due to other parts that are miss-
ing), so reducing the inventory carrying costs.
Commonly, an e-commerce protocol involving
multiple parties ensures strong fairness if after the
protocol execution all parties will receive their ex-
pected items or none do.
In the literature, we find multi-party fair exchange
e-commerce protocols with applications in buying
physical products (AlTawy et al., 2017), digital prod-
ucts (Liu, 2009) and digital signature of contracts
(Ferrer-Gomila and Hinarejos, 2021). These propos-
als do not consider any intermediaries.
Instead, there are few solutions that consider inter-
mediaries in different multi-party scenarios: consid-
Bîrjoveanu, C. and Bîrjoveanu, M.
Secure E-Commerce Protocol with Complex Trading Capabilities of Intermediaries.
DOI: 10.5220/0012127100003555
In Proceedings of the 20th International Conference on Security and Cryptography (SECRYPT 2023), pages 495-502
ISBN: 978-989-758-666-8; ISSN: 2184-7711
Copyright
c
 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)
495

ering only one intermediary (Carbonell et al., 2009;
Onieva et al., 2004), and considering more inter-
mediaries (Draper-Gil et al., 2013), (B
ˆ
ırjoveanu and
B
ˆ
ırjoveanu, 2020). In (Carbonell et al., 2009), a
customer can buy products from several providers
through an intermediary agent integrated in 3-D Se-
cure Protocol. In this solution, the intermediary can
not perform aggregate transactions, because in the
same transaction (in which the customer buys many
products), the authorization process is realized sepa-
rately for each individual buying request. Also, the
optional transactions are not considered. In (Onieva
et al., 2004) is proposed a protocol for exchange of
non-repudiation evidences, but without dealing with
aggregate or optional transactions. In (B
ˆ
ırjoveanu
and B
ˆ
ırjoveanu, 2020), a multi-party protocol that al-
lows a customer to fairly acquire physical products
from different providers through many intermediaries
is proposed. However, in this solution the intermedi-
aries are restricted to perform only chained transac-
tions, without the capability to perform aggregate or
optional transactions. In (Draper-Gil et al., 2013), the
intermediaries are used to enable contract signing be-
tween multiple parties ensuring only weak fairness, in
a different scenario then the one approached in our pa-
per. Although this solution considers aggregate trans-
action, it does not consider optional transaction.
The complex transactions rise new challenges for
assuring strong fairness, that are not appearing in two-
party transactions. An issue appears when the cus-
tomer successfully buys only a part of the components
of an aggregate product. In this case, strong fairness is
ensured for all transactions composing the aggregate
transaction, but strong fairness for the entire aggre-
gate transaction is not guaranteed. Another issue ap-
pears when the customer successfully buys more than
one product in an optional transaction. Strong fairness
for the optional transaction is not assured, although
strong fairness is guaranteed for all transactions com-
posing the optional transaction. In a chained trans-
action an intermediary can buy a product on demand,
but afterward he cannot provide it to the customer or
intermediary who requested it due to various reasons
(insufficient funds, malicious behavior, etc). In this
case, strong fairness for all transactions belonging to
the chained transaction is satisfied, even if strong fair-
ness for the chained transaction is not satisfied.
Contributions The related work presented above
emphasizes the absence of multi-party e-commerce
protocols considering intermediaries with complex
trading capabilities. In this paper, we propose the first
multi-party e-commerce protocol that allows inter-
mediaries to perform aggregate, chained or optional
transactions depending on the received request. These
complex trading capabilities of the intermediaries are
more appropriate to the real world applications, such
as supply chain scenarios. Ensuring strong fairness
is a challenging issue in environments where multiple
parties are involved, as we showed above. We design
the complex transaction protocol using a modular ap-
proach by designing a sub-protocol for each type of
transaction from the complex transaction.
This design approach allows us to demonstrate
the correctness of our complex transaction protocol
proposal by demonstrating the correctness of each
sub-protocol using Cl-AtSe model checker. The for-
mal specification and verification is challenging be-
cause we must take into consideration the communi-
cations performed between sub-protocols when they
are integrated in the complex transaction protocol.
The verification results prove that our complex trans-
action protocol satisfies all aimed security require-
ments: strong fairness, effectiveness, timeliness, non-
repudiation and confidentiality.
The paper is structured as follows: Sect. 2 presents
an use case of our protocol, Sect. 3 defines security
requirements, Sect. 4 describes our protocol. Sect. 5
sketches the security analysis of our protocol and
Sect. 6 contains the conclusion.
2 APPLICATIONS
A toy company KidsBots (KB) is preparing the pro-
duction for a new toy robot. To start the production, it
needs the following components: motherboard, 32 led
panel, 12V DC motors, and body plastic parts (bp).
KB identify the necessary components from the on-
line catalog of MasterBroker (MB) intermediary. For
the motherboard, KB identified two options having
similar features: Motherboard ITX (mb
1
), and if it is
not available, Motherboard 4 (mb
2
). For 32 led panel,
KB needs the model 32LP (l p). The toy company
has three options for 12V DC motors: FastDC (m
1
)
or HpDC (m
2
) or MetalDC (m
3
). So, KB prepares
its order to acquire from MB the needed parts, as a
complex transaction: ((mb
1
∨mb
2
)∧l p) ∧(m
1
∨m
2
∨
m
3
) ∧ bp. ∧ represents an aggregate transaction, and
∨ an optional one. The complex transaction is an ag-
gregate transaction in which the first component is an
aggregate transaction, the second is an optional trans-
action and third is an individual product. The complex
transaction is illustrated in Fig. 1.
After MB receives the request from KB, it splits
it in three components: places the order for (mb
1
∨
mb
2
) ∧ l p to PCBShop, the order for (m
1
∨ m
2
∨ m
3
)
to SensorActuatorComp (SensA), and the order for bp
to PlasticRoboP. When receiving the order for (mb
1
∨
SECRYPT 2023 - 20th International Conference on Security and Cryptography
496

KidsBots (B
0
)
((mb
1
\/mb
2
) /\ lp) /\ (m
1
\/m
2
\/m
3
) /\ bp
MasterBroker (B
1
)
PCBShop (B
2
)
MBest (B
3
)
Robotix
ITMaster
mb
1
mb
2
lp
MLed (B
4
)
mb
1
\/mb
2
(mb
1
\/mb
2
) /\ lp
lp
LedP
SensA (B
3
)
MotorC (B
4
)
SGear
m
3
m
1
\/m
2
\/m
3
m
1
\/m
2
\/m
3
m
1
m
2
MCHPMotor
PlasticRoboP (B
4
)
bp
QPieces (B
5
)
SPiecesC
bp
(B
4
)
(B
5
)
(B
5
)
(B
5
)
(B
6
)
(B
7
)
(B
6
)
bp
Figure 1: Supply chain applications.
mb
2
) ∧ l p, PCBShop places an order for (mb
1
∨ mb
2
)
to MBest that initiates in its turn an order to the
provider Robotix to acquire mb1, but if this is not
available, afterward initiates an order to the provider
ITMaster for mb
2
. To acquire l p, PCBShop initiates
a transaction with MLed that in its turn initiates a
chained transaction with the provider LedP.
In Fig. 1, the intermediaries colored in blue per-
form aggregate transactions, the one colored in red
perform optional transactions and the one colored in
magenta perform chained transactions. The green
color is associated to the providers.
3 SECURITY REQUIREMENTS
In our Protocol with Complex Trading Capabilities of
Intermediaries (PCTCI) we want to ensure the fol-
lowing security requirements: strong fairness, effec-
tiveness, timeliness, non-repudiation, and confiden-
tiality. We will introduce these security requirements.
Strong Fairness. We will gradually define it,
from two-party to multi-party scenarios. A two-party
e-commerce sub-protocol ensures strong fairness if
after its execution, the party that initiates the sub-
protocol receives a successful payment evidence from
the corresponding receiver and the receiver receives
the payment for the product from the correspond-
ing initiator (successful subtransaction), or none do
(aborted subtransaction). A chained e-commerce sub-
protocol ensures strong fairness if after its execu-
tion, either all subtransactions from chain are suc-
cessfully completed, or all are aborted. An aggre-
gate e-commerce sub-protocol ensures strong fairness
if after its execution, either all component subtransac-
tions of aggregate transaction are successfully com-
pleted, or all are aborted. An optional e-commerce
sub-protocol ensures strong fairness if after its exe-
cution, either only one component subtransaction of
optional transaction is successful, or all are aborted.
PCTCI ensures strong fairness if after its execu-
tion, any instance of two-party, aggregate, optional
and chained sub-protocol ensures strong fairness and
all of them provides the same fairness level (either all
aggregate, optional and chained transactions are suc-
cessful, or all are aborted).
Effectiveness requires that if every party involved
in PCTCI behaves honestly and no communication er-
ror occurs, then after protocol execution strong fair-
ness is guaranteed, with success of complex transac-
tion, without Trusted Third Party (TTP) mediation.
PCTCI guarantees timeliness if any party in-
volved in PCTCI can be sure that protocol execution
will be finished at a certain finite point of time without
losing strong fairness.
Non-repudiation in PCTCI prevents any party to
falsely deny its involvement in PCTCI.
PCTCI ensures confidentiality if the message’s
content communicated between the participating par-
ties is not accessible to unauthorized parties.
4 THE PROTOCOL
The following participants are involved in PCTCI: the
customer, the intermediaries, the providers, the pay-
ment gateway and the bank. The payment gateway
is used as interface between intermediaries/providers
and the bank to facilitate making payments. Ta-
ble 1 presents the notations used in the description
of PCTCI, and Table 2 provides the detailed struc-
ture of the protocol’s messages. The communication
channels between PG and any other party are con-
sidered resilient, through which messages can be de-
layed but not lost (Onieva et al., 2009). The commu-
nication channels between any other parties are un-
reliable, meaning that the messages can be lost. We
consider that each participant has the digital certifi-
cates for the public keys of each participant he com-
municates with. C searches the needed products in the
intermediary’s online catalog, order them as a com-
plex transaction and send it to the intermediary when
C clicks the ”submit” button. The intermediary ac-
quires the products requested by C from many others
intermediaries/providers, any intermediary acquiring
in his turn the products by performing any type of
transaction: aggregate, optional or chained.
Next, we give an overview about the protocol’s
functionality. C initiates PCTCI sending PO
0,1
to B
1
.
To accomplish C’s request, B
1
initiates a transaction
t
1,k
, sending PO
1,m
to the intermediary/provider B
m
,
where 2 ≤ m ≤ k. The transaction t
1,k
can be at
1,k
,
ot
1,k
or s
1,k
. Each intermediary B
m
can initiate an ag-
gregate, optional or chained transaction. This pro-
cess continue until the providers are reached. The
complex transaction is completed backwards from the
providers through intermediaries until C, as follows.
Each provider sends to the intermediary from which
received the purchase request, the corresponding pay-
Secure E-Commerce Protocol with Complex Trading Capabilities of Intermediaries
497

Table 1: Notations used in the protocol description.
Notation Interpretation
P, C, PG, B
i
Set of providers, Identity of Customer, Payment Gateway, Intermediary (Broker) i; B
0
= C;
s
i, j
One-to-one subtransaction initiated by B
i
with B
j
at
i, j
/ ot
i, j
One-to-many aggregate / optional transaction initiated by B
i
with B
i+1
,...,B
j
t
i, j
Transaction s
i, j
, at
i, j
or ot
i, j
PO
i, j
/ PR
i, j
Purchase Order of B
i
to B
j
/ Payment Request of B
j
to get payment from B
i
PE
i, j
/ APE
i, j
Payment Evidence of B
i
and B
j
in s
i, j
/ Aborted Payment Evidence of B
i
and B
j
in s
i, j
E
j,k
Payment Evidence in t
j,k
that B
j
sends to B
i
in s
i, j
X → Z : m A party X sends the message m to a party Z
X ⇒ B
i
: m
i
A party X simultaneously sends the messages m
i
to the set of parties {B
i
/1 ≤ i ≤ n}
{m}
PkX
{m}
K
,{K}
PkX
- hybrid encryption of m with PkX using the AES session symmetric key K
SigX(m); Y /A RSA digital signature of X on h(m), where h is a hash function; Y ES/ABORT
Table 2: Protocol messages details.
PO
i, j
= {PM
i
, OI
i
}
PkB
j
PM
i
= {PI
i
, SigB
i
(PI
i
}
PkPG
PI
i
= B
i
, Cn
i
, Ot p
i
, Id
i, j
, Am
i, j
, B
j
OI
i
= B
i
, B
j
, Pid
i, j
, Id
i, j
, Am
i, j
, SigB
i
(B
i
, B
j
, Pid
i, j
, Id
i, j
, Am
i, j
)
PR
i, j
= {PM
i
, Pid
i, j
, SigB
j
(Pid
i, j
, Id
i, j
, B
i
, B
j
, Am
i, j
)}
PkPG
Pid
i, j
=





Pid
i, j
, if B
j
∈ P (1.1)
PE
j,k
.Pid, if t
j,k
= s
j,k
and PE
j,k
.Resp = Y (1.2)
PE
j, j+1
.Pid,..., PE
j,k
.Pid, if t
j,k
= at
j,k
and PE
j,m
.Resp = Y , for all j + 1 ≤ m ≤ k (1.3)
PE
j,m
.Pid, if t
j,k
= ot
j,k
and PE
j,m
is the first evidence with PE
j,m
.Resp = Y , j+1≤ m ≤ k (1.4)
PE
i, j
= Resp,B
i
,B
j
,Id
i, j
,Pid
i, j
,SigPG(Resp, B
i
,B
j
,Id
i, j
,Pid
i, j
,Am
i, j
),E
i, j
E
i, j
= Resp,Id
i, j
,Pid
i, j
,SigPG(Resp, Id
i, j
,Pid
i, j
)
PE
i, j
.Pid/PE
i, j
.Am - The product identifier Pid/ amount Am from PE
i, j
PE
i, j
.Resp/E
i, j
.Resp - The response Resp in PE
i, j
/E
i, j
Am
i, j
is defined in a similar manner as Pid
i, j
by replacing Pid with Am in the definition of Pid
i, j
above
E
j,k
=





Cert(B
j
), if B
j
∈ P (2.1)
E
j,k
, if t
j,k
= s
j,k
and E
j,k
.Resp = Y (2.2)
E
j, j+1
,...,E
j,k
, if t
j,k
= at
j,k
and E
j,m
.Resp = Y , for all j + 1 ≤ m ≤ k (2.3)
E
j,m
, if t
j,k
= ot
j,k
and E
j,m
is the first evidence with E
j,m
.Resp = Y , j+1≤ m ≤ k (2.4)
E
j,k
.Resp - The sequence of responses from all evidences from E
j,k
E
j,k
.Resp = Y - The responses from all evidences from E
j,k
are Y
APE
i, j
= A,B
i
,B
j
,Id
i, j
,Pid
i, j
,SigPG(A,B
i
,B
j
,Id
i, j
,Pid
i, j
,Am
i, j
,PE
i, j
),AE
i, j
AE
i, j
= A,Id
i, j
,Pid
i, j
,SigPG(A,Id
i, j
,Pid
i, j
,E
i, j
)
ment evidence obtained from PG. The success or
abortion of each s
i, j
depends not only on the success-
ful/aborted PE
i, j
corresponding to s
i, j
, but also on the
success/abortion of the transaction t
j,k
that follows s
i, j
(meaning successful/aborted payment evidence E
j,k
computed by B
j
in t
j,k
). Thus, B
i
is ensured that s
i, j
is
successfully completed only if it receives from B
j
two
successful payment evidences: PE
i, j
and E
j,k
. Conse-
quently, B
i
is assured that either the whole sequence
of transactions starting with s
i, j
is successfully com-
pleted or aborted. Finally, C receives from B
1
the cor-
responding PE
0,1
and E
1,k
, assuring him about suc-
cess or abortion the entire complex transaction. In
PCTCI we identify 3 possible behaviors of B
j
:
1. B
j
receives a request from B
i
in s
i, j
and to fulfill
it, he decides to send a new request to B
k
in s
j,k
.
2. B
j
receives an aggregate request from B
i
in s
i, j
and to fulfill it, he decides to send k − j requests
to B
j+1
,.. .,B
k
in an aggregate transaction at
j,k
.
3. B
j
receives an optional request from B
i
in s
i, j
and
to fulfill it, he sends at most k − j requests to
B
j+1
,.. .,B
k
in an optional transaction ot
j,k
.
For each of the above behaviors of B
j
, we describe a
sub-protocol played by him. So, the Chained Trans-
action sub-protocol (CTP) corresponds to case 1, Ag-
gregate Transaction sub-protocol (ATP) to case 2, and
Optional Transaction sub-protocol (OTP) to case 3.
PCTCI consists of CTP, ATP, OTP, Resolution 1 sub-
protocol (Res1) and Resolution 2 sub-protocol (Res2)
that will be described in the next sections.
SECRYPT 2023 - 20th International Conference on Security and Cryptography
498

Table 3: Chained Transaction sub-protocol played by B
j
.
1. B
i
→ B
j
: PO
i, j
2. if (B
j
∈ P) B
j
→ PG : PR
i, j
3. PG → B
j
: {PE
i, j
}
PkB
j
4. B
j
→ B
i
: {PE
i, j
, Cert(B
j
)}
PkB
i
5. else B
j
→ B
k
: PO
j,k
6. if (B
k
→ B
j
: {PE
j,k
, E
k,l
}
PkB
j
in s
j,k
,
7. with PE
j,k
.Resp = Y and
E
k,l
.Resp = Y )
8. B
j
→ PG : PR
i, j
9. PG → B
j
: {PE
i, j
}
PkB
j
10. if (PE
i, j
.Resp=Y ) B
j
→ B
i
: {PE
i, j
, E
j,k
}
PkB
i
11. else B
j
→ B
i
: {PE
i, j
}
PkB
i
; Res1(B
j
) end if
12. else if (B
k
→ B
j
: {PE
j,k
,E
k,l
}
PkB
j
, with
13. PE
j,k
.Resp ̸= A) Res2(B
j
) end if
14. B
j
→ PG : {PE
j,k
, PM
i
, OI
i
}
PkPG
15. PG → B
j
: {PE
i, j
}
PkB
j
16. PG → B
i
: {PE
i, j
}
PkB
i
17. end if end if
4.1 Chained Transaction Sub-Protocol
In this section, we will describe CTP played by an in-
termediary or provider B
j
that receives a product pur-
chase request from C or other intermediary B
i
in s
i, j
.
CTP played by B
j
is presented in Table 3. We con-
sider that in any subtransaction, a provider supplies
only one individual product. If B
j
is a provider, then
in s
i, j
he delivers to B
i
the product requested by him.
If B
j
is an intermediary, then he can receive from B
i
a
request for an individual, aggregate or optional prod-
uct. In this case, B
j
initiates a new s
j,k
with B
k
to
acquire the product requested by B
i
.
In s
i, j
, B
i
sends PO
i, j
to B
j
to buy a physical prod-
uct. B
i
builds PO
i, j
by encrypting with B
j
’s public
key of the payment message PM
i
and the order infor-
mation OI
i
. PM
i
contains the payment information
PI
i
provided by B
i
and the signature of B
i
on PI
i
, both
encrypted with PG’s public key. PI
i
consists of card
number Cn
i
, one-time password Ot p
i
issued by bank,
the identifier Id
i, j
and the amount Am
i, j
. Each s
i, j
is
uniquely identified by an identifier Id
i, j
generated as
follows: Id
i, j
= Id
r,i
N
i, j
, where N
i, j
is a fresh random
number generated by B
i
and Id
r,i
is the identifier of the
previous subtransaction s
r,i
. If i = 0, then Id
r,i
is the
empty string. So, the identifier of a subtransaction is
the sequence of all numbers generated in all previous
subtransactions until it. OI
i
includes the identities of
the intermediaries, the product identifier Pid
i, j
, Id
i, j
,
Am
i, j
and B
i
’s signature on these information.
Upon reception of PO
i, j
, B
j
checks the order in-
formation. If B
j
is provider (line 2), then he sends
PR
i, j
to PG to get payment from B
i
. PR
i, j
is built from
PM
i
, Pid
i, j
and B
j
’s signature on the information de-
scribed in Table 2. PG checks PI
i
’s authenticity, and
checks Cn
i
and Ot p
i
to verify that B
i
is authorized to
use the card. By verifying B
j
’s signature, PG is en-
sured that B
i
and B
j
agreed on Pid
i, j
, Am
i, j
and Id
i, j
.
PG sends to B
j
an aborted PE
i, j
(Resp=A) in case
some of above checks are failed. If all checks are suc-
cessful, PG sends the payment message to the bank.
Depending on B
i
’s account balance, the bank makes
or not the transfer in the B
j
’s account providing to
PG a successful (Resp=Y ) or aborted PE
i, j
. PG sends
PE
i, j
to B
j
(line 3) and stores it together with PR
i, j
.
B
j
decrypts {PE
i, j
}
PkB
j
, checks PE
i, j
’s authen-
ticity and sends {PE
i, j
,Cert(B
j
)}
PkB
i
to B
i
, where
Cert(B
j
) is the provider certificate. Upon reception,
B
i
checks the authenticity of Cert(B
j
) and PE
i, j
.
If B
j
is not the provider (line 5), then he stores
PO
i, j
and initiates s
j,k
with B
k
by sending PO
j,k
to
buy Pid
i, j
requested by B
i
. In this case, to respond the
request received from B
i
, B
j
must ensure that either
all the transactions that follows s
i, j
have been success-
fully completed, or all have been aborted.
s
j,k
is aborted if B
j
and B
k
received the aborted
PE
j,k
. s
j,k
is successful if B
k
received a successful
PE
j,k
and B
j
received two successful evidences: PE
j,k
and E
k,l
. E
k,l
is the evidence in t
k,l
that B
k
sends to B
j
to inform it that t
k,l
was successfully finished.
E
j,k
is defined depending on the type of transac-
tion initiated by B
j
with B
k
. As we can see in def.
(2.1) Table 2, if B
j
is provider, then E
j,k
is Cert(B
j
).
In case B
j
initiates s
j,k
with B
k
, then E
j,k
is E
j,k
from
the successful PE
j,k
(def. (2.2) Table 2).
We remark that the role of E
k,l
is essential in the
way the sequence of transactions starting with s
i, j
is
finished. Therefore (at line 6) in s
j,k
, B
j
waits to re-
ceive PE
j,k
and E
k,l
from B
k
. The success of both
PE
j,k
and E
k,l
(line 7) ensures B
j
that the sequence of
transactions starting with s
j,k
is successfully finished
and consequently (line 8) B
j
sends PR
i, j
to PG in s
i, j
.
PR
i, j
includes the identifier Pid
i, j
of the product suc-
cessfully purchased by B
j
in s
j,k
(def. (1.2) Table 2),
and the amount Am
i, j
(see Table 2). B
j
checks PE
i, j
and if it is successful, then sends it together with E
j,k
to B
i
(line 10). B
i
checks the success of PE
i, j
, PG’s
signatures to verify the evidence’s authenticity and
also the corresponding identifiers to ensure the fresh-
ness of evidences and their belonging to successive
subtransactions. If all checks are satisfied, then PE
i, j
ensures B
i
that s
i, j
was successful and the successful
E
j,k
ensures B
i
that s
j,k
was successful. If B
j
receives
from PG an aborted PE
i, j
, then he sends it to B
i
(line
11) as a proof of s
i, j
abortion, and applies Res1 to
abort the sequence of transactions starting with s
i, j
.
Res1 will be detailed below in Sect. 4.4.
Secure E-Commerce Protocol with Complex Trading Capabilities of Intermediaries
499

Table 4: Aggregate Transaction sub-protocol played by B
j
.
1. B
i
→ B
j
: PO
i, j
2. a = 0;
3. B
j
⇒ {B
m
/ j + 1 ≤ m ≤ k} : PO
j,m
4. B
m
→ B
j
: {PE
j,m
, E
m,l
}
PkB
j
in s
j,m
, j+1≤m≤k
5. for (m = j + 1; m ≤ k; m = m + 1)
6. if (not (PE
j,m
.Resp = Y and E
m,l
.Resp = Y ))
7. a = m; break; end if end for
8. if (a = 0)
9. B
j
→ PG : PR
i, j
10. PG → B
j
: {PE
i, j
}
PkB
j
11. if (PE
i, j
.Resp = Y ) B
j
→ B
i
: {PE
i, j
, E
j,k
}
PkB
i
12. else B
j
→ B
i
: {PE
i, j
}
PkB
i
; Res1(B
j
) end if
13. else B
j
→ PG : {PE
j, j+1
,..., PE
j,k
,PM
i
,OI
i
}
PkPG
14. for (m = j + 1; m ≤ k; m = m + 1)
15. if (PE
j,m
.Resp=Y ) PG → B
j
: {APE
j,m
}
PkB
j
16. PG → B
m
: {APE
j,m
}
PkB
m
17. Res1(B
m
) end if
18. else if (PE
j,m
.Resp ̸= A) Res2(B
j
) end if
19. end if end for
20. PG → B
j
: {PE
i, j
}
PkB
j
21. PG → B
i
: {PE
i, j
}
PkB
i
22. end if
If B
j
receives from B
k
an invalid message, or a
successful PE
j,k
but E
k,l
is missing or contains at least
an aborted evidence (lines 12 − 13), then he applies
Res2 sub-protocol to abort the sequence of transac-
tions starting with s
j,k
. Res2 sub-protocol will be de-
tailed in Sect. 4.5. Further, to abort s
i, j
, B
j
sends to
PG (line 14) a request containing PM
i
, OI
i
and the
aborted PE
j,k
. PG checks PE
j,k
, PM
i
and OI
i
for their
authenticity, and aborts s
i, j
by generating the aborted
PE
i, j
and sends it to B
i
and B
j
.
Therefore, after applying CTP by B
j
, either all
transactions starting with s
i, j
are successfully fin-
ished, or all aborted.
4.2 Aggregate Transaction Sub-Protocol
Table 4 describes ATP played by B
j
that receives an
aggregate request PO
i, j
from B
i
in s
i, j
and to fulfill it,
he initiates an aggregate transaction at
j,k
. ATP’s mes-
sages are represented in Fig. 2. After B
j
checks PO
i, j
,
he initiates at
j,k
by simultaneously sending PO
j,m
to
the set of intermediaries {B
m
/ j + 1 ≤ m ≤ k} (line 3).
The product required by B
j
to B
m
in each s
j,m
, is a
component of the aggregate product required by B
i
.
How B
j
responds to the request from B
i
depends
on the success/failure of all transactions that follows
s
i, j
. So, before responding to B
i
’s request, B
j
must
ensure that at
j,k
is successful or aborted. Thus, at the
line 4, B
j
receives from B
m
, the payment evidences
.
.
.
.
.
.
B
i
{PE
i,j
, E
j,k
}
PkB
i
PO
i,j
B
j
PG
{PE
i,j
}
PkB
j
PR
i,j
s
i,j
.
.
.
t
k,l
PG
PO
j,j+1
{
PE
j,j+1
,E
j+1,l
}
PkB
j
B
j+1
{PE
j,j+1
}
PkB
j+1
PR
j,j+1
PO
j,k
{
PE
j,k
, E
k,l
}
PkB
j
B
k
PG
{
PE
j,k
}
PkB
k
PR
j,k
at
j,k
.
.
.
.
.
.
.
.
.
t
j+1,l
Figure 2: ATP’s messages flow played by B
j
.
corresponding to the request sent by him to B
m
in
s
j,m
. In this step, either B
j
receives the evidences
from all B
j+1
,.. .,B
k
or only from a part of them, or
from none (e.g., due to network communication er-
rors). The variable a is used to store the first aborted
substransaction from at
j,k
, if it exists. In the for loop
(lines 5-7), B
j
checks if all s
j,m
from at
j,k
are success-
ful. If in iteration m of the for loop, both evidences
received by B
j
from B
m
in s
j,m
are successful (PE
j,m
in s
j,m
and E
m,l
from t
m,l
), then B
j
is ensured that all
transactions starting with s
j,m
are successful. Other-
wise, a will store m (line 7).
If after for loop, a is 0, then at
j,k
is successful and
B
j
sends PR
i, j
to PG in s
i, j
(line 9). PR
i, j
includes
Pid
i, j
that contains the sequence of product’s iden-
tifiers successfully purchased by B
j
in all successful
subtransactions from at
j,k
(def. (1.3) Table 2). On re-
ception of a successful PE
i, j
from PG, B
j
sends it to-
gether with E
j,k
to B
i
(line 11). In this case, E
j,k
is the
sequence of all successful evidences E
j, j+1
,.. .,E
j,k
(def. (2.3), Table 2). Upon reception, B
i
is ensured
that s
i, j
and at
j,k
are successful. If B
j
receives from
PG an aborted PE
i, j
, then s
i, j
is aborted. In this case,
B
j
sends PE
i, j
to B
i
(line 12) and applies Res1 to abort
the sequence of transactions starting with s
i, j
.
If after for loop, a ̸= 0, then a will store a value
m such that s
j,m
is the first aborted subtransaction
from at
j,k
. In this case, at least s
j,m
from at
j,k
is
aborted. But, there are subtransactions of at
j,k
that are
successfully completed (at least s
j, j+1
,.. .,s
j,m−1
).
Consequently, at
j,k
has both aborted and successful
subtransactions. To obtain fairness, we must en-
sure that all sequences of transactions starting with
s
j, j+1
,.. .,s
j,k
are aborted. For this, B
j
sends to PG
(line 13) a request containing PE
j, j+1
,.. .,PE
j,k
, PM
i
and OI
i
. PG checks the authenticity of all received
components, and if checks are passed, he sends to the
bank B
j
’s request to abort each successful s
j,m
(line
15). The bank cancels the transfer from B
j
into B
m
’s
account, aborts the successful PE
j,m
by generating the
corresponding APE
j,m
as in Table 2, and sends it to
PG. Also, PG forwards APE
j,m
to B
j
and B
m
as a
proof of s
j,m
’s abortion (lines 15-16). Further, Res1
SECRYPT 2023 - 20th International Conference on Security and Cryptography
500

Table 5: Optional Transaction sub-protocol played by B
j
.
1. B
i
→ B
j
: PO
i, j
2. a = 0;
3. for (m = j + 1; m ≤ k; m = m + 1)
4. B
j
→ B
m
: PO
j,m
5. if (B
m
→ B
j
: {PE
j,m
,E
m,l
}
PkB
j
,
6. with PE
j,m
.Resp = Y and E
m,l
.Resp = Y )
7. B
j
→ PG : PR
i, j
8. PG → B
j
: {PE
i, j
}
PkB
j
9. if (PE
i, j
.Resp=Y ) B
j
→ B
i
: {PE
i, j
,E
j,k
}
PkB
i
10. else B
j
→ B
i
: {PE
i, j
}
PkB
i
; Res1(B
j
) end if
11. a = m; break;
12. else if (B
m
→ B
j
: {PE
j,m
,E
m,l
}
PkB
j
,
13. with PE
j,m
.Resp ̸= A) Res2(B
j
) end if
14. end if end for
15. if (a = 0)
16. B
j
→ PG : {PE
j, j+1
,..., PE
j,k
,PM
i
,OI
i
}
PkPG
17. PG → B
j
: {PE
i, j
}
PkB
j
18. PG → B
i
: {PE
i, j
}
PkB
i
end if
is applied by B
m
to abort the sequence of transactions
starting with s
j,m
(line 17). In case of PE
j,m
is missing
or cannot be understood by PG (line 18), then Res2
sub-protocol is applied by B
j
to abort the sequence
of transactions starting with s
j,m
. PG aborts s
i, j
by
generating the aborted PE
i, j
and sends it to B
i
and B
j
.
Therefore, after applying ATP by B
j
, either all
transactions starting with s
i, j
are successfully fin-
ished, or all aborted.
4.3 Optional Transaction Sub-Protocol
OTP played by B
j
is described in Table 5. B
j
receives
an optional request PO
i, j
from B
i
in s
i, j
(line 1) and
he initiates the optional transaction ot
j,k
(for loop). B
j
initiates s
j, j+1
,.. .,s
j,k
, in this order (line 4), until one
of these is successfully completed or all of them are
aborted. The variable a is used to store the first suc-
cessful substransaction from ot
j,k
, if it exists. If in the
mth iteration of for loop, B
j
receives both successful
PE
j,m
and
E
m,l
from B
m
(lines 5-6), then B
j
is ensured
that s
j,m
is successfully completed. This corresponds
to the success of ot
j,k
. In this case, B
j
sends PR
i, j
to PG (line 7). If B
j
receives a successful PE
i, j
from
PG, then he sends it together with E
j,k
(=E
j,m
) to B
i
(line 9). Upon reception, B
i
is ensured that s
i, j
and
ot
j,k
were successful. Otherwise, if B
j
receives from
PG an aborted PE
i, j
, then he sends it to B
i
(line 10)
and applies Res1 to abort the sequence of transactions
starting with s
i, j
. If in mth iteration, B
j
receives from
B
m
an invalid message, or a successful PE
j,m
but E
m,l
is missing or aborted (lines 12-13), then he applies
Res2 sub-protocol.
Table 6: Resolution 1 Sub-protocol.
Res1(B
j
)
for (r = j + 1; r ≤ j + n; r = r + 1)
if (PE
i, j
.Resp = A and PE
j,r
.Resp = Y )
B
j
→ PG : {PE
i, j
,PE
j,r
}
PkPG
else if (exists APE
i, j
and PE
j,r
.Resp = Y )
B
j
→ PG : {APE
i, j
,PE
j,r
}
PkPG
end if end if
PG → B
j
: {APE
j,r
}
PkB
j
PG → B
r
: {APE
j,r
}
PkB
r
Res1(B
r
)
end for
If the value of a is 0 after for loop, then ot
j,k
is
aborted. In this case, to maintain fairness, B
j
sends to
PG (line 16) a request to abort s
i, j
. PG checks the re-
ceived request, generates the aborted PE
i, j
and sends
it to B
i
and B
j
to abort s
i, j
. As a result, after apply-
ing OTP by B
j
, either s
i, j
and exactly one option from
ot
j,k
are successfully finished, or all subtransactions
starting with s
i, j
are aborted.
4.4 Resolution 1 Sub-Protocol
Let be n, the maximum number of subtransactions in
any aggregate or optional transaction. If in the com-
plex transaction, s
i, j
is the first aborted subtransaction
from the sequence of transactions starting with s
i, j
,
then fairness in PCTCI is not ensured. This is because
all the transactions t
j, j+n
,t
j+1, j+n+1
,.. .,t
j+n, j+2n
,.. .,
from the transactions sequence that follows s
i, j
are
successful, and s
i, j
is aborted. So, there is an unfair
case for B
j
: he has paid for products in the success-
ful t
j, j+n
, but he cannot supply them to B
i
. To ensure
fairness, B
j
applies Res1 described in Table 6 to abort
the sequence of transactions starting with s
i, j
.
Each iteration r of the for loop recursively aborts
the sequence of transactions starting with s
j,r
, where
j + 1 ≤ r ≤ j + n. For the aborted s
i, j
, B
j
has ei-
ther an aborted PE
i, j
or an APE
i, j
. To abort s
j,r
, B
j
sends PE
i, j
/APE
i, j
and the successful PE
j,r
to PG.
PG checks them, aborts s
j,r
by generating APE
j,r
, and
sends it to B
j
and B
r
. Next, Res1 is recursively ap-
plied by each next intermediary B
r
.
4.5 Resolution 2 Sub-Protocol
If in s
i, j
, B
i
sends PO
i, j
, but he receives from B
j
in-
valid evidences, or a successful PE
i, j
but E
j,k
is miss-
ing or contains at least an aborted evidence, then fair-
ness is not ensured. In this scenario, there is an unfair
case for B
i
: after he sends PO
i, j
, he waits from B
j
ev-
idences that ensures him about successful or aborted
s
i, j
, but he does not receive evidences to confirm that.
In this case, for any s
i, j
, we define a timeout t in which
Secure E-Commerce Protocol with Complex Trading Capabilities of Intermediaries
501

B
i
waits the payment evidences from B
j
. If t expires
and B
i
receives from B
j
invalid evidences, or a suc-
cessful PE
i, j
but E
j,k
is missing or contains at least
an aborted evidence, then B
i
initiates Res2 with PG to
abort the sequence of transactions starting with s
i, j
.
For this, B
i
sends to PG a request containing PM
i
, OI
i
and the invalid evidences (if these are received).
PG checks PM
i
, OI
i
and any invalid evidences. If PG
finds in its database a successful PE
i, j
, then PG aborts
it by generating APE
i, j
. If PG finds in its database an
aborted PE
i, j
, then will send it to B
i
and B
j
. If PG
doesn’t find PE
i, j
, then he generates an aborted PE
i, j
.
In all cases, PG sends the aborted evidence to B
i
and
B
j
as a proof of aborting s
i, j
. Further, B
j
applies Res1
to abort the sequence of transactions starting with s
i, j
.
As a result, fairness is also ensured for B
i
.
5 FORMAL VERIFICATION
To formally verify PCTCI, we use Cl-AtSe
(Constraint-Logic based Attack Searcher) model
checker (Turuani, 2006) from AVISPA (Automated
Validation of Internet Security Protocols and Appli-
cations) (Vigano, 2006), widely used by academic
and industry researchers in the field of security
protocols. An overview of the AVISPA tool and
how to use it to formally verify complex protocols
is provided in (B
ˆ
ırjoveanu and B
ˆ
ırjoveanu, 2022).
The formal proof that PCTCI satisfies the security
requirements demands the formal proof that each
of the sub-protocols ATP, OTP and CTP of PCTCI
satisfies the corresponding security requirements. A
detailed description of PCTCI’s formal verification
and full specification can be found at (B
ˆ
ırjoveanu and
B
ˆ
ırjoveanu, 2023)). Our specification includes also
use cases that require application of Res1 and Res2
sub-protocols.
Our results regarding the formal verification
of ATP, OTP and CTP using Cl-AtSe prove that
the following security requirements are satisfied:
strong fairness, strong authentication, confidential-
ity, non-repudiation and integrity. In (B
ˆ
ırjoveanu and
B
ˆ
ırjoveanu, 2023), we show how PCTCI derives its
security requirements based on security requirements
guaranteed in each of its sub-protocols.
6 CONCLUSIONS
In this paper, we proposed an e-commerce protocol
with applications in supply chain, that distinguishes
from the existing solutions by enabling the intermedi-
ary agents to perform aggregate, chained and optional
transactions. All these features add complexity com-
pared to the tradition e-commerce model. So, guar-
anteeing security requirements like strong fairness,
effectiveness, timeliness, non-repudiation and confi-
dentiality is challenging. We overcome this challenge
and formally proved using AVISPA that our proposal
ensures the required security properties.
REFERENCES
AlTawy, R., ElSheikh, M., Youssef, A., and Gong, G.
(2017). Lelantos: A blockchain-based anonymous
physical delivery system. In PST’17, 15th Annual
Conference on Privacy, Security and Trust. IEEE.
B
ˆ
ırjoveanu, C. V. and B
ˆ
ırjoveanu, M. (2020). Fair ex-
change e-commerce protocol for multi-chained com-
plex transactions. In 17th International Joint Confer-
ence on e-Business and Telecommunications - Volume
2: ICE-B. SCITEPRESS.
B
ˆ
ırjoveanu, C. V. and B
ˆ
ırjoveanu, M. (2022). Formal Ver-
ification of Multi-party Fair Exchange E-Commerce
Protocols. In: Secure Multi-Party E-Commerce Pro-
tocols. SpringerBriefs in Computer Science. Springer.
B
ˆ
ırjoveanu, C. V. and B
ˆ
ırjoveanu, M.
(2023). Formal Verification of PCTCI.
https://github.com/PCTCIDevelopers/PCTCI-
Verification Last accessed May 23, 2023.
Carbonell, M., Sierra, J. M., and Lopez, J. (2009). Secure
multiparty payment with an intermediary entity. Com-
puters & Security.
Draper-Gil, G., Zhou, J., Ferrer-Gomila, J. L., and Hinare-
jos, M. F. (2013). An optimistic fair exchange proto-
col with active intermediaries. International Journal
of Information Security.
Ferrer-Gomila, J. L. and Hinarejos, M. F. (2021). A multi-
party contract signing solution based on blockchain.
Electronics.
Liu, Y. (2009). An optimistic fair protocol for aggregate ex-
change. In FITME’09, 2nd International Conference
on Future Information Technology and Management
Engineering. IEEE.
Onieva, J., Zhou, J., Lopez, J., and Carbonell, M. (2004).
Agent-mediated non-repudiation protocols. Elec-
tronic Commerce Research and Applications.
Onieva, J. A., Lopez, J., and Zhou, J. (2009). Secure Multi-
Party Non-Repudiation Protocols and Applications.
Springer.
Turuani, M. (2006). The cl-atse protocol analyser. In
17th International Conference on Rewriting Tech-
niques and Applications. Springer.
Vigano, L. (2006). Automated security protocol analysis
with the avispa tool. Electronic Notes in Theoretical
Computer Science.
SECRYPT 2023 - 20th International Conference on Security and Cryptography
502