what is i i kp kp i kp i kp i i key key protocol protocol
play

What is i i KP KP? ? i KP i KP: : i i - -Key Key- -Protocol - PDF document

What is i i KP KP? ? i KP i KP: : i i - -Key Key- -Protocol Protocol What is i -Key-Protocol, i = 1, 2, 3, Family of protocols Secure electronic payment Based on credit card payments Christopher Hsu Can be extended


  1. What is i i KP KP? ? i KP i KP: : i i - -Key Key- -Protocol Protocol What is � i -Key-Protocol, i = 1, 2, 3, … � Family of protocols � Secure electronic payment � Based on credit card payments Christopher Hsu � Can be extended to debit card and check payments 3/12/2004 1 3/12/2004 2 History of i i KP KP Initial Assumptions History of Initial Assumptions � 1995, IBM Research Labs Zurich and � Only partial privacy is emphasized Watson Research Centre � Encryption not used in protocol � Open industry standard � Can be implemented by other means � Incorporated into SEPP, SET � Or protocol can be extended � Z i P: fully operational prototype � i KP emphasizes the payment � Did not become commercial product � Assumes purchase order is already � But has been deployed in some known businesses 3/12/2004 3 3/12/2004 4 Parties and Attackers Acquirer Requirements Parties and Attackers Acquirer Requirements � Three parties: Acquirer (A), Merchant � A1. Proof of transaction (M), Customer (C) authorization of customer � Three attackers: eavesdropper, � A2. Proof of transaction active attacker, insider authorization by merchant 3/12/2004 5 3/12/2004 6 iKP 1

  2. Merchant Requirements Customer Requirements Merchant Requirements Customer Requirements � M1. Proof of transaction � C1. Unauthorized payment is authorization by acquirer impossible � M2. Proof of transaction � C2. Proof of transaction authorization by customer authorization by acquirer � C3. Certification and authentication of merchant � C4. Receipt from merchant 3/12/2004 7 3/12/2004 8 Extra Customer Requirements Components of the Protocol Extra Customer Requirements Components of the Protocol � C5. Privacy � Keys: PK X , SK X , CERT X � C6. Anonymity � Cryptography: H(.), E X (.), S X (.) � Quantities: SALT C , PRICE, DATE, NONCE M , ID M , TID M , DESC, CAN, R C , CID, Y/N, PIN, V � Discuss 1KP in detail, comparison with 2KP and 3KP 3/12/2004 9 3/12/2004 10 1KP Protocol Flow Removing Nonce and Date 1KP Protocol Flow Removing Nonce and Date Initiate: C � M SALT C , CID Initiate: C � M SALT C , CID Invoice: C � M Clear Invoice: C � M Clear Payment: C � M EncSlip Payment: C � M EncSlip* Auth-Request: M � A Clear, H(DESC,SALT C ), EncSlip Auth-Request: M � A Clear, H(DESC,SALT C ), EncSlip* Auth-Response: M � A Y/N, Sig A Auth-Response: M � A Y/N, Sig A Confirm: C � M Y/N, Sig A Confirm: C � M Y/N, Sig A Common: PRICE, ID M , TID M , DATE, NONCE M , CID, H(DESC,SALT C ) Common: PRICE, ID M , TID M , DATE, NONCE M , CID, H(DESC,SALT C ) Clear: ID M , TID M , DATE, NONCE M , H(Common) Clear: ID M , TID M , DATE, NONCE M , H(Common) SLIP: PRICE, H(Common), CAN, R C , [PIN] SLIP: PRICE, H(Common), CAN, R C , [PIN] EncSlip: E A (SLIP) EncSlip: E A (SLIP) Sig A : S A (Y/N, H(Common)) Sig A : S A (Y/N, H(Common)) 3/12/2004 11 3/12/2004 12 iKP 2

  3. Removing SALT C Removing SALT C : Invariant Removing SALT Removing SALT C : Invariant C Initiate: C � M SALT C , CID -- Intruder never knows desc and salt Invoice: C � M Clear from same customer Payment: C � M EncSlip invariant "Intruder does not know DESC" Auth-Request: M � A Clear, H(DESC,SALT C ), EncSlip forall i: IntruderId do Auth-Response: M � A Y/N, Sig A forall j: CustomerId do Confirm: C � M Y/N, Sig A !int[i].descs[j] | !int[i].salts[j] Common: PRICE, ID M , TID M , DATE, NONCE M , CID, H(DESC,SALT C ) Clear: ID M , TID M , DATE, NONCE M , H(Common) end SLIP: PRICE, H(Common), CAN, R C , [PIN] end; EncSlip: E A (SLIP) Sig A : S A (Y/N, H(Common)) 3/12/2004 13 3/12/2004 14 What is not fulfilled? 2KP and 3KP What is not fulfilled? 2KP and 3KP � Acquirer’s proof of transaction � Satisfies deficiencies of 1KP authorization by merchant � Differs in the number of public keys � Merchant’s proof of transaction available authorization by customer � Guarantees more undeniable � Customer’s certification and receipts for the transaction authentication of merchant � Customer’s receipt from merchant 3/12/2004 15 3/12/2004 16 2KP Protocol Flow 2KP Additions 2KP Protocol Flow 2KP Additions Initiate: C � M SALT C , CID � Merchant has public/private key and Invoice: C � M Clear, Sig M , CERT M certificate Payment: C � M EncSlip � Acquirer has certification and Auth-Request: M � A Clear, H(DESC,SALT C ), EncSlip, Sig M , CERT M Auth-Response: M � A Y/N, Sig A authentication of merchant Confirm: C � M Y/N, V, Sig A � Customer has certification and Common: PRICE, ID M , TID M , DATE, NONCE M , CID, H(DESC,SALT C ), H(V) Clear: ID M , TID M , DATE, NONCE M , H(V), H(Common) authentication of merchant SLIP: PRICE, H(Common), CAN, R C � Customer has receipt from merchant EncSlip: E A (SLIP) Sig A : S A (Y/N, H(Common)) Sig M : S M (H(Common), H(V)) 3/12/2004 17 3/12/2004 18 iKP 3

  4. 3KP Protocol Flow 3KP Additions 3KP Protocol Flow 3KP Additions Initiate: C � M SALT C , CID, CERT C � Customer has public/private key and Invoice: C � M Clear, Sig M certificate Payment: C � M EncSlip, Sig C Auth-Request: M � A Clear, H(DESC,SALT C ), EncSlip, Sig M , Sig C � Merchant has proof of transaction Auth-Response: M � A Y/N, Sig A authorization by customer Confirm: C � M Y/N, V, Sig A Common: PRICE, ID M , TID M , DATE, NONCE M , CID, H(DESC,SALT C ), H(V) Clear: ID M , TID M , DATE, NONCE M , H(V), H(Common) SLIP: PRICE, H(Common), CAN, R C EncSlip: E A (SLIP) Sig A : S A (Y/N, H(Common)) Sig M : S M (H(Common), H(V)) Sig C : S C (EncSlip, H(Common)) 3/12/2004 19 3/12/2004 20 i KP KP Comparison Overview Comparison Overview i KP KP Summary Summary i i Requirements / Protocols 1KP 2KP 3KP � 1KP: simple, merchant is not A1. Proof of Transaction Authorization by Customer * * ** authenticated, order and receipt are A2. Proof of Transaction Authorization by Merchant ** ** deniable M1. Proof of Transaction Authorization by Acquirer ** ** ** � 2KP: merchant is authenticated M2. Proof of Transaction Authorization by Customer ** � 3KP: non-repudiation for all C1. Unauthorized Payment is Impossible * * ** messages C2. Proof of transaction Authorization by Acquirer * * ** C3. Certification and Authentication of Merchant ** ** � Intended for gradual deployment C4. Receipt from Merchant ** ** 3/12/2004 21 3/12/2004 22 Bibliography Bibliography Bellare, Mihir et al . Design, Implementation and Deployment 1. of the i KP Secure Electronic Payment System. IEEE Journal of Selected Areas in Communications, VOL 18, NO. 4, April 2000. Bellare, Mihir et al . i KP – A Family of Secure Electronic 2. Payment Protocols. 1995. 3/12/2004 23 iKP 4

Recommend


More recommend