[ Pobierz całość w formacie PDF ]

its own key KA, and sends the ciphertext EKA(M), together
devices to exchange tickets, e.g., using P2P networks. How-
with its identity, to the proxy in a Request-for-Encryption
ever, for simplicity and efficiency, we take a centralized ap-
(RE) message. The proxy keeps a cache of all REs received
proach in which the exchange is assisted by the proxy in an
in the past Tm seconds, which is the minimum time allowed
oblivious manner.
between two consecutive exchanges for a device. When the
In our ticket exchange process, there are two types of de-
proxy receives a RE from A, it checks whether the cache
vices, namely traders and tradees. When a smartphone reg-
already has a RE from A. If RE already exists, it sim-
isters with the proxy, it randomly picks up a type with equal
ply drops the newly received RE. Otherwise, encrypts the
probability. That is, roughly half of the devices are traders,
received EKA(M) using its own key KP . The result, i.e.,
and the other half are tradees. The proxy maintains a list of
EKP (EKA(M)), is denoted by X1. The proxy returns X1 to
currently active tradees. When a tradee needs to exchange
A.
tickets, it simply notifies the proxy, which then adds it into
Now A is ready to initiate ticket exchange with B. To do
-1
the list. On the other hand, when a trader needs to ex-
so, A decrypts X1 using KA and sends the result EKA(X1)
change tickets, it queries the proxy for active tradees using
to B. On the other hand, B first encrypts the received
-1 -1
an IP-based channel. Upon receiving such query, the proxy
EKA(X1) using KB. The result, i.e., EKB (EKA(X1)), is
randomly picks up a tradee from the current list and returns
denoted by X2. Next B sends X2 to the proxy in a Request-
it to the requesting trader. The trader then contacts the re-
for-Decryption (RD) message. The proxy then decrypts X2
-1
turned tradee and exchanges tickets through SMS. Once the
using KP and returns the result EKP (X2) to B. Finally, B
transaction is completed, the tradee notifies the proxy and -1
decrypts the received EKP (X2) using KB. The result, i.e.,
has itself removed from the list of active tradees.
-1 -1
EKB (EKP (X2)), is denoted by X3.
Essentially, the traders and the tradees use the proxy s
At this time, B is able to verify whether A is indeed a
assistance to find each other and facilitate ticket exchange.
valid trader, because based on the commutative property,
However, because the traders query the proxy over an IP-
based channel, the proxy does not know the identity of the -1 -1 -1
X3 = EKB (EKP (EKB (EKA(EKP (EKA(M)))))) = M
requesting trader. This way, the proxy cannot track the
ticket exchange transactions, hence does not know what tick-
This result is not surprising because A, B and the proxy each
ets a device has after the exchange.
applies one encryption and one decryption operation, using
However, the above protocol works only if all smartphones
their respective keys. Due to the commutative property,
are benign. A malicious or infected smartphone can easily
the final result should be exactly the original Transaction
disrupt it by repeatedly querying for tradees and exchanging
Description. Thus, B can check the final result X3 and
tickets with all of them. As a result, the malicious device can
exchange tickets with A only if it includes both A and B.
collect a large number of valid tickets and then successfully
Clearly, without the assistance from the proxy, a trader
inject bogus reports. To defeat such cheating behavior, we
cannot complete the above process and successfully exchange
enhance the ticket exchange process as follows.
tickets with any tradee. Since the proxy only allows a trader
Cheating Prevention To prevent cheating in ticket ex-
to invoke the encryption once every Tm seconds, a trader
change, our basic idea is to ensure each device can only
can exchange tickets no faster than once per Tm seconds.
trade once within a fairly large amount of time, say one day.
Despite its conceptual complexity, the cheating prevention
This is difficult because the traders actions (i.e., querying
mechanism is actually light-weight. For each transaction of
for tradees and exchanging tickets) must be oblivious to the
ticket exchange, it incurs only 5 messages, 3 encryption op-
proxy; otherwise, the proxy is able to track the transac-
erations and 3 decryption operations. Such overhead can
tions. In what follows, we describe how the proxy can limit
be further amortized by exchanging multiple tickets in one
the trading rate of a trader, without knowing whom it ex-
transaction, so that it is invoked less frequently.
changes tickets with.
Our cheating prevention mechanism is based on commu-
5.3 Anonymous Alert Strategy
tative encryption [24]. For any message M and two keys K1 The proposed anonymous report submission scheme can [ Pobierz całość w formacie PDF ]

  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • szkla.opx.pl

    •