Security Game. Security-GameΠ,A(η) : params → Setup(1η) v → AO,D(params) (l, t) → Trajectory(v) p, b → Result(v) winif if b = 1 and p < P((l, t)) were the adversary A has access to an oracle Ð which on input a vehicle iden- tifier v and a GPS coordinate g, models the (physical) movement of vehicle v from the current location to GPS coordinates g. If g corresponds to a cell c checkpoints then the oracle provides the corresponding evidence to the TSP. has also access to an oracle which allows her to communicate to the other parties (in this case the SE and the TSP) in the ETP protocol Π. The function Trajectory, on input a vehicle identifier v returns a vector of pairs Location Time, corresponding to the trajectory of vehicle v that has been sub- mitted to the oracle during the previous billing period. The function Result, on input a vehicle identifier v returns the toll charge p which v has to pay as a result of the last Update protocol run, together with a bit b which equals one when no fraud has been detected for vehicle v. The function is overloaded in the definition to vectors of Location Time pairs and computes the correct price of this trajectory.
Security Game. We are going to define security as follows: EU-CMA Challenger Adversary Generates: (sk, vk) → Gen 1 vk Repeat
m(i) Calculate s: σ(i) → Signsk m(i) σ(i) m∗, σ∗ Vervk (m∗, σ∗) = 1 And m∗ ∈/ m(i) We define the advantage: EU — CMA — Adv [A] = Pr [A wins] It turns out that we can construct a signature scheme from only OWF (unlike public key encryption).
Security Game. Our 2SM security game is essentially the two-party restriction of our DCGKA security game, with every message counting as an update message, except that we use IND-CPA security instead of secret indistinguishability. The oracles of our security game appear in Figure 10. The init oracle sets up the game and all the variables needed to keep track of the execution. The random bit b is used for IND-CPA challenges. The states of the two parties, A and B, are initialized using key pairs for a public-key encryption scheme PKE. ciphertextsA[c] and plaintextsA[c] store the ciphertext and plaintext, respectively, for the c-th message sent by A, and likewise for B. The ciphertexts arrays are marked public, indicating that they are readable by the adversary, and the parties’ public keys are returned to the adversary. After calling init, the adversary is free to call the remaining oracles to simulate message sending and receiving, corrupt the parties’ states, and issue IND-CPA challenges. Note that deliver-A enforces authentic in-order delivery of messages from B (if the require statement fails, the game aborts and the adversary loses). However, messages can be arbitrarily delayed, and messages from the two parties may be interleaved. deliver-A checks that A correctly decrypts the original plaintext, enforcing correctness (otherwise win reveals b to the adversary). At the end of the game, the predicate 2SM-safe in Figure 11 is evaluated on the sequence of queries q1, . . . , qq made by the adversary, and if it is false, the adversary loses. This is to prevent trivial attacks, in which the adversary corrupts a group member’s state and then uses it directly to decrypt a message. Specifically, 2SM-safe(q1, . . . , qq) fails to hold if there are queries qi = corrupt-A, qj = challenge-B(m0, m1) such that A had not yet received the message corresponding to qj at the time of qi, unless A healed this corruption by sending a message after qi that was delivered to B before qj, and likewise with A and B swapped. An attacker wins the 2SM security game if it correctly guesses the random bit b in the end and the safety predicate 2SM-safe evaluates to true on the queries made by the attacker.
