Fulltext - International Journal of Computer Technology and ...

More documents

Recommendations

Info

Q 0 generates encryption and MAC keys, x k and x mk [2][6] respectively, using the key generation algorithms kgen and mkgen. Q 0 returns control to the adversary by the output α(). Q A and Q B represent the actions of A and B. Step 2: a) Role of A: Sanjay Kumar Sonkar et al ,Int.J.Computer Technology & Applications,Vol 3 (2), 525-531 A→B: e = {xˋk}x k , mac(e, x mk ) xˋk fresh Q A = β i ≤ n C A (); new xˋk : key; new x″ r :coins; Let xm : bitstring = enc(k2b(xˋk), x k , x″ r ) in C A β i ≤ n represents n copies, indexes by i ϵ [1,n] The protocol can be run n times (polynomial in the security parameter [4]). The process is triggered when a message is sent on C A by the adversary. The process chooses a fresh key xˋk and sends the message on channel C A . We obtain a sequence of games G 0 ≈ G 1 ≈ … ≈ G m , which implies G 0 ≈ G m . If some equivalence or trace property hold with overwhelming probability in G m , then it also hold with overwhelming probability in G 0 . Step 5: Security definition [1][2][9]: A MAC scheme: (Randomized) key generation function mkgen. MAC function mac (m, k) takes as input a message m and a key k. Verification function verify(m, k, t) such that Verify (m, k, mac (m, k)) = true. ISSN:2229-6093 A MAC guarantees the integrity and authenticity [26] of the message because only someone who knows the secret key can build the mac. More formally, an adversary A that has oracle access to mac and verify has a negligible probability to forge a MAC: b) Role of B: A→B: e = {xˋk}x k , mac(e, x mk ) xˋk fresh Q B = β i ≤ n C B (xˋm : bitstring, x ma : macstring); if veriry (xˋm , x mk , x ma ) than let i ⊥ (k2b(x″ k )) = dec (xˋm, x k ) in C B () n copies, as for Q A . The process Q B waits for the message on channel C B . It verifies the MAC, decrypts and stores the key in x″ k . Step 3: Indistinguishability as observational equivalence: Two processes Q1, Q2 are observationally equivalent where the adversary has a negligible probability of distinguishing them: Q 1 ≈ Q 2 In the formal definition, the adversary is represented by an acceptable evaluation context C:: = C|Q & Q|C new Channel c; C. Observation equivalence is an equivalence relation. It is contextual: Q 1 ≈ Q 2 implies C[Q] ≈ C[Q] where C is any acceptable evaluation context. Step 4: Proof Technique: We transform a Game G 0 into an observationally equivalent [27][28] on using: Observational equivalences: L ≈ R given as axioms and that come from security assumptions on primitives. These equivalences are used inside a context: G1 ≈ C[L] C[R] ≈ G2 Syntactic transformations: Simplification, expansion of assignments, max Pr[verify (m, k, t) | k ← mkgen; (m, t) ← A mac (. , k), verify(. , k, .) ] A is negligible, when the adversary A has not called the mac oracle on message m. Step 6: Intuitive Implementation: By the previous definition, up to neglible probability, The adversary cannot forge a correct MAC. So when verifying a MAC with verify (m, k, t) and k ← mkgen is used only for generating and verifying MACs, the verification can succeed only if m is in the list (array) of message whose mac has been computed by the protocol. So we can replace a call to verify with an array lookup: If the call to mac is mac (x, k), we replace verify (m, k, t) with find j ≤ N such that defined (x[j]) ˄ (m = x[j]) ˄ verify (m, k, t) then true else false. Step 7: Formal implementation (1) [15]: Verify (m, mkgen(r), mac(m, mkgen(r))) = true β N″ new r : mkeyseed; (β N (x : bitstring) → mac(x, mkgen(r)), β Nˋ(m : bitstring, t : macstring) → verify(m, mkgen(r), t)) ≈ β N″ new r : mkeyseed; (β N (x : bitstring) → mac(x, mkgen(r)), β Nˋ(m : bitstring, t : macstring) → find j ≤ N such that defined(x[j]) ˄ (m = x[j]) ˄ verify(m, mkgen(r), t) then true else false. Formal implementation (2): Verify (m, mkgen(r), mac(m, mkgen(r))) = true β N″ new r : mkeyseed; (β N (x : bitstring) → mac(x, mkgen(r)), β Nˋ(m : bitstring, t : macstring) → verify(m, mkgen(r), t)) 526
Sanjay Kumar Sonkar et al ,Int.J.Computer Technology & Applications,Vol 3 (2), 525-531 ≈ β N″ new r : mkeyseed; (β N (x : bitstring) → macˋ(x, mkgenˋ(r)), β Nˋ(m : bitstring, t : macstring) → find j ≤ N such that defined(x[j]) ˄ (m = x[j]) ˄ verifyˋ(m, mkgenˋ(r), t) then true else false. The prover applies the previous rule automatically in any (polynomial-time) context, perhaps containing several occurrences of mac and verify following: ISSN:2229-6093 prove the source of the message to a third party. A practical secure deniable authentication protocol should have the following properties: Completeness or authentication, strong deniability, weak deniability, security of forgery attack, security of impersonate attack, security of compromising session secret attack, security of man-in-the-middle attack. Each occurrence of mac is replaced with macˋ. Each occurrence of verify is replaced with a message key and find that looks in all arrays of computed MACs. Step 8: Proof of security properties: a. One-session secrecy: The adversary cannot distinguish any of the secretes from a random number with one test query. Criterion for proving one-session secrecy [19][21] of x: X is defined by new x[i] : T and there is a set of variables S such that only variables in S depend on x. The output messages and the control-flow do not depend on x. b. Secrecy: The adversary cannot distinguish the secrets from independent random numbers with several test queries. Criterion for proving secrecy of x: Same as one-session secrecy, plus x[i] and x[iˋ] do not come from the same copy of the same restriction when i ≠ iˋ. Step 9: Result: In most cases, the prover succeeds in proving the desired properties when they hold and obviously it always fails to prove them when they do not hold. Only cases in which the prover fails although the property holds: Needham-Schroeder [9][11] public-key when the exchanged key is the nonce N A. Needham-Schroeder shared-key: fails to prove that N B [i] ≠ N B [iˋ]-1 with overwhelming probability, where N B is a nonce. III. Analysis Model Deniable authentication protocols allow a Sender to authenticate a message for a receiver, in a way that the receiver cannot convince a third party that such authentication (or any authentication) ever took place. Deniable authentication has two characteristics that differ from traditional authentication: One is that only the intended receiver can authenticate the true source of a given message; the other is that the receiver cannot provide the evidences to Figure 1: Analysis model of deniable authentication protocols with Blanchet calculus Generally deniable authentication protocol includes three roles, Sender which is initiator, receiver which is responder and third party, represented by Sender, Receiver and Third party, respectively. We assume that Sender plays only on the role of the initiator; Receiver plays only the role of responder, Third party play only on the prover. The deniable authentication protocol consists of a sequence of messages exchanged between the Sender and the Receiver & the Receiver and Third party. In deniable authentication protocol Sender can authenticate a message for Receiver, in a way that they cannot Receiver convince a Third party that such authentication (or any authentication) ever took place. Deniable authentication protocol has two characteristics that differ from traditional authentication protocol. One is that only the intended Receiver can authenticate the true source of a given message. The other is that the Sender cannot provide the evidences to prove the source of the message to a third party at some condition and the Receiver can provide the evidences to prove the source of the message to a third party. The ability of adversary is defined in the previous section. It can control the channel SR between Sender and Receiver. It cannot control the channels: Channel ST and channel RT. At the same time the adversary is a probabilistic polynomial-time attacker. Strong deniability: The purpose of strong deniability is to protect the privacy of Sender. After execution of the deniable authentication protocol the Sender can deny to have ever authenticated anything to Receiver. If the prover (Receiver or the any other party) wants to prove that the Sender have authenticated messages to Receiver, they must provide all the relevant evidence. The Sender can provide his secret information to the Third party. A adversary model in strong deniability: we suppose that the Sender and the Receiver cooperate with the judge or the prover or the any other party 527
Page 1: Sanjay Kumar Sonkar et al ,Int.J.Co
Page 5 and 6: Sanjay Kumar Sonkar et al ,Int.J.Co
Page 7: Sanjay Kumar Sonkar et al ,Int.J.Co

Fulltext - International Journal of Computer Technology and ...

Create successful ePaper yourself

Delete template?

Save as template?