5.3 A Formal Model for Electronic Payment
5.3.2 Confirmation is Key
Since the human initiator of a transaction can never be sure that an input device correctly processes his transaction data, he needs a way of confirming the transaction data with the bank before the transaction is processed. We formalize this confirmation mechanism within the ideal functionality FCONF (specified in Figure 5.2). FCONF is a two-party functionality which allows a sender to transmit a message and the receiver of the message to confirm or reject it. As with the ideal payment functionality, the adversary gets the chance to force a confirmation with a certain probability, modeling the insecurity inherent to real-world protocols which use short secrets. Note that he can always force the confirmation to be rejected.
To realize FPAY, we need authenticated communication from the bank to the receiver, so that the receiver can be notified of the transaction. For most real-world payment protocols, this authenticated communication is easy to establish, since receivers are electronic devices and not humans. In the case of cash withdrawal, the bank owns the money dispensing unit and can pre-distribute cryptographic keys to establish authenticated communication.
Using FCONFand FAUTH [21], we propose a protocolπPAY which realizes
FPAY. This protocol is informally depicted in Figure 5.3.
Theorem 28. Let I, B, R, and D(R) ITMs, where I is human, and B and R are honest. Then, πPAY, informally depicted in Figure 5.3, UC-
The Ideal Functionality for Electronic Payment FPAY,D(I, B, R). Parametrized by a set of receiversSR, a designated receiver R ∈ SR, a
set of initiatorsSI, an initiatorI ∈ SI, the bankB and a parametrized
distribution D.
InitializeI0 = I, R0 = R, attacked = no.
Assertion: At any time, I, I0 ∈ SI and R, R0 ∈ SR. If the assertion is
violated, halt.
Phase 1: Collecting Information
1. Upon receipt of message (transfer, sid , R, m$) from I: Send
(sid , I, R, m$) to the adversary, receive (sid , I0, R0, m0$) and out-
put(input-received, sid , I0, R0, m0
$) to B.
Phase 2: Confirmation and Execution 2. Resume upon instruction by the adversary.
3. IfI0 is honest,(I0, R0, m0$) 6= (I, R, m$) and attacked = no, halt.
4. Make a public delayed output of(received, sid , I0, m0 $) to R
0.
Phase 3: Ensuring Consistency
5. Resume upon instruction by the adversary and make a public delayed output of (processed, sid , I0, R0, m0
$) to B. Halt upon
confirmation by the adversary. Attack
• Upon receiving an input (attack, sid ) in Phase 2 from the adversary, sample an elementb ∈ {confirm, reject} according to D(m0$). If b = confirm, set attacked = yes, otherwise set attacked = no. Return(attack, sid , attacked ) to the adversary. Ignore all further attack queries.
The Ideal Functionality for Confirmation FCONF,D(S, C)
Parameters: The message senderS, the respective confirmer C and a parametrized distribution D.
Initialize attacked = no, initiated = no, completed = no.
• Upon receiving (initiate, sid , C, m) from ITI S, make a public delayed output of (initiate, sid , S, m) to C and set initiated = yes. Ignore all subsequent initiate messages.
• Upon receiving (reply, sid , S, b) from ITI C when initiated = yes, completed = no and b ∈ {confirm, reject}: Make a public delayed output of (answer, sid , C, b) to S. Upon confirmation from the adversary, set completed = yes and halt.
• Upon receiving (force-confirm, sid ) from the adversary, assert thatC is honest, initiated = yes, completed = no and attacked = no. If this holds, set attacked = yes and sample an element b ∈ {confirm, reject} according to D(m). If b = confirm, set completed = yes and make a public delayed output of (answer, sid , C, confirm) to S and halt upon confirmation by the
adversary. Otherwise, return (fail, sid ) to the adversary.
• Upon receiving (force-reject, sid ) from the adversary, assert that C is honest, initiated = yes, completed = no and attacked = no. If this holds, set attacked = yes and completed = yes, make a public delayed output of (answer, sid , C, reject) to S and halt upon confirmation by the adversary. Otherwise, return (fail, sid ) to the adversary.
I D(R) B R output (transfer, R, m$) Phase 1: (transfer, I, R, m$) (input-received, I, R, m$) (initiate, I, (I, R, m$)) Phase 2: (answer, B, confirm) (pay, I, m$) (received, I, m$) (completed, R) Phase 3: (processed, I, R, m$)
Figure 5.3: The protocolπPAYrealizing FPAY,D(I, B, R) using FCONF,D(B, I),
FAUTH(B, R) and FAUTH(R, B), the latter two depicted as . The use
of an imperfect FCONF,D is depicted via . The protocol is between the human initiatorI, the ATM D(R), the bank B and the money dispenser R. The protocol proceeds in three phases, namely (1) the information collection phase, (2) the confirmation and execution phase and (3) the phase which ensures a consistent view on what happened.
realizes FPAY,D(I, B, R) in the FAUTH(B, R), FAUTH(R, B), FCONF,D(B, I)-
hybrid model.
Proof. To proof our statement, we consider a series of hybrid experimentsHi,
starting with the real execution between the environment Z, the real-world (dummy) adversary A and the real protocol parties in H0. We gradually
change the execution until we end with the execution of the ideal protocol for FPAY between the environment Z, the simulator S and dummy parties
for FPAY in H5. We give a specific simulator for each of the steps, such that
each step is indistinguishable (even perfectly so) from the previous one. Due to the transitivity of indistinguishability, it then follows that the real and ideal execution are perfectly indistinguishable.
Hybrid H0. This denotes the real execution of πPAY between Z, the ad-
versary A and real protocol parties.
Hybrid H1. For H1 we make the following changes. First, we encapsulate
the parties and ideal functionalities from the real protocol within a new Interactive Turing Machine (ITM) which we call S1 (the simulator). Second,
we add a dummy party for each party from the real protocol. These dummy parties interact with an ideal functionality F1 that relays all inputs to the
simulator and receives back outputs. S1 just simulates the behavior of the real protocol and performs outputs via F1 as necessary.
We argue that H1 and H2 are perfectly indistinguishable. As the ideal
functionality F1 immediately reports inputs to S1 and allows it to make
arbitrary outputs in the name of all parties, S1 is able to perfectly simulate the real parties’ protocol.
HybridH2. H2 is identical toH1, except that F1 is replaced with the ideal
functionality F2 that works as follows:
• Behave like FPAY for Phase 1 (Collecting Information).
• Do not allow direct outputs of input-received-messages from S2 in
the name ofB.
S2 is the same as S1 with the exception that, ifI is corrupted, S2 inputs the
(transfer)-message himself upon instruction of Z
We argue that H2 and H1 are perfectly indistinguishable. With the
restrictions imposed on the simulator by the new ideal functionality, two deviations become possible: eitherB outputs a different value in H2 than in
H1 or, when I is corrupted, it does not send the message to start a transfer
when instructed. The second case can be handled by S2. It remains to argue thatB’s output remains unchanged.
IfI inputs a (transfer)-message, F2 sends(sid , I, R, m$) to the simulator
which contains all of the original information and allows him to continue his perfect simulation of the real protocol. With this knowledge, S2 can advise F2 to output the input-received-message to B at the right time.
HybridH3. InH3 we make the following changes to the ideal functionality:
• Behave like FPAY for Phase 2 (Confirmation and Execution).
• Add the attack interface of FPAY.
• Do not allow direct outputs of received-messages in the name of R. S3 works exactly as S2.
We argue that H3 and H2 are perfectly indistinguishable. The main
difference between the two hybrid models is that the simulator can no longer directly influence the output of the receiver. If the adversary is instructed to perform an attack on the confirmation channel in the real protocol, the simulator can use the attack interface to simulate the attack. This, however, is no problem, since the execution of Phase 2 only resumes upon instruction of the simulator and he can thus instruct an attack beforehand and cause the ideal functionality to accept changed transaction details from Phase 1.
In all other cases, the simulator can simply instruct the ideal functionality to continue, based on the output of the receiver in the simulation of the real protocol. If any changes toI, R or m$ are necessary, the simulator can do so
via the ideal functionality in Phase 1.
The output of the receiver is thus the same inH2 and H3.
Hybrid H4. HybridH4 is identical toH3, except that F3 is replaced with
FPAY,D. This means, that the simulator can no longer make outputs of processed-message in the name ofB.
We argue that H4 and H3 are perfectly indistinguishable. This is trivially the case, since the simulator will only instruct the ideal functionality to deliver the processed-message toB if he sees this message in his simulation of the real protocol. If any changes toI, R or m$ have been necessary, the
simulator would have performed them in the previous stages.
Even though this might seem unsurprising at first, this allows to break down the complexity of realizing FPAY into two easier problems: realizing a confirmation mechanism between the initiator and the bank and realizing authenticated communication between the receiver and the bank.