1 / 23

i KP: i -Key-Protocol

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

sullivanj
Download Presentation

i KP: i -Key-Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. iKP: i-Key-Protocol Christopher Hsu

  2. What is iKP? • i-Key-Protocol, i = 1, 2, 3, … • Family of protocols • Secure electronic payment • Based on credit card payments • Can be extended to debit card and check payments

  3. History of iKP • 1995, IBM Research Labs Zurich and Watson Research Centre • Open industry standard • Incorporated into SEPP, SET • ZiP: fully operational prototype • Did not become commercial product • But has been deployed in some businesses

  4. Initial Assumptions • Only partial privacy is emphasized • Encryption not used in protocol • Can be implemented by other means • Or protocol can be extended • iKP emphasizes the payment • Assumes purchase order is already known

  5. Parties and Attackers • Three parties: Acquirer (A), Merchant (M), Customer (C) • Three attackers: eavesdropper, active attacker, insider

  6. Acquirer Requirements • A1. Proof of transaction authorization of customer • A2. Proof of transaction authorization by merchant

  7. Merchant Requirements • M1. Proof of transaction authorization by acquirer • M2. Proof of transaction authorization by customer

  8. Customer Requirements • C1. Unauthorized payment is impossible • C2. Proof of transaction authorization by acquirer • C3. Certification and authentication of merchant • C4. Receipt from merchant

  9. Extra Customer Requirements • C5. Privacy • C6. Anonymity

  10. Components of the Protocol • Keys: PKX, SKX, CERTX • Cryptography: H(.), EX(.), SX(.) • Quantities: SALTC, PRICE, DATE, NONCEM, IDM, TIDM, DESC, CAN, RC, CID, Y/N, PIN, V • Discuss 1KP in detail, comparison with 2KP and 3KP

  11. Initiate: CM Invoice: CM Payment: CM Auth-Request: MA Auth-Response: MA Confirm: CM SALTC, CID Clear EncSlip Clear, H(DESC,SALTC), EncSlip Y/N, SigA Y/N, SigA 1KP Protocol Flow Common: PRICE, IDM, TIDM, DATE, NONCEM, CID, H(DESC,SALTC) Clear: IDM, TIDM, DATE, NONCEM, H(Common) SLIP: PRICE, H(Common), CAN, RC, [PIN] EncSlip: EA(SLIP) SigA: SA(Y/N, H(Common))

  12. Initiate: CM Invoice: CM Payment: CM Auth-Request: MA Auth-Response: MA Confirm: CM SALTC, CID Clear EncSlip* Clear, H(DESC,SALTC), EncSlip* Y/N, SigA Y/N, SigA Removing Nonce and Date Common: PRICE, IDM, TIDM, DATE, NONCEM, CID, H(DESC,SALTC) Clear: IDM, TIDM, DATE, NONCEM, H(Common) SLIP: PRICE, H(Common), CAN, RC, [PIN] EncSlip: EA(SLIP) SigA: SA(Y/N, H(Common))

  13. Initiate: CM Invoice: CM Payment: CM Auth-Request: MA Auth-Response: MA Confirm: CM SALTC, CID Clear EncSlip Clear, H(DESC,SALTC), EncSlip Y/N, SigA Y/N, SigA Removing SALTC Common: PRICE, IDM, TIDM, DATE, NONCEM, CID, H(DESC,SALTC) Clear: IDM, TIDM, DATE, NONCEM, H(Common) SLIP: PRICE, H(Common), CAN, RC, [PIN] EncSlip: EA(SLIP) SigA: SA(Y/N, H(Common))

  14. Removing SALTC: Invariant -- Intruder never knows desc and salt from same customer invariant "Intruder does not know DESC" forall i: IntruderId do forall j: CustomerId do !int[i].descs[j] | !int[i].salts[j] end end;

  15. What is not fulfilled? • Acquirer’s proof of transaction authorization by merchant • Merchant’s proof of transaction authorization by customer • Customer’s certification and authentication of merchant • Customer’s receipt from merchant

  16. 2KP and 3KP • Satisfies deficiencies of 1KP • Differs in the number of public keys available • Guarantees more undeniable receipts for the transaction

  17. Initiate: CM Invoice: CM Payment: CM Auth-Request: MA Auth-Response: MA Confirm: CM SALTC, CID Clear, SigM, CERTM EncSlip Clear, H(DESC,SALTC), EncSlip, SigM, CERTM Y/N, SigA Y/N, V, SigA 2KP Protocol Flow Common: PRICE, IDM, TIDM, DATE, NONCEM, CID, H(DESC,SALTC), H(V) Clear: IDM, TIDM, DATE, NONCEM, H(V), H(Common) SLIP: PRICE, H(Common), CAN, RC EncSlip: EA(SLIP) SigA: SA(Y/N, H(Common)) SigM: SM(H(Common), H(V))

  18. 2KP Additions • Merchant has public/private key and certificate • Acquirer has certification and authentication of merchant • Customer has certification and authentication of merchant • Customer has receipt from merchant

  19. Initiate: CM Invoice: CM Payment: CM Auth-Request: MA Auth-Response: MA Confirm: CM SALTC, CID, CERTC Clear, SigM EncSlip, SigC Clear, H(DESC,SALTC), EncSlip, SigM, SigC Y/N, SigA Y/N, V, SigA 3KP Protocol Flow Common: PRICE, IDM, TIDM, DATE, NONCEM, CID, H(DESC,SALTC), H(V) Clear: IDM, TIDM, DATE, NONCEM, H(V), H(Common) SLIP: PRICE, H(Common), CAN, RC EncSlip: EA(SLIP) SigA: SA(Y/N, H(Common)) SigM: SM(H(Common), H(V)) SigC: SC(EncSlip, H(Common))

  20. 3KP Additions • Customer has public/private key and certificate • Merchant has proof of transaction authorization by customer

  21. iKP Comparison Overview

  22. iKP Summary • 1KP: simple, merchant is not authenticated, order and receipt are deniable • 2KP: merchant is authenticated • 3KP: non-repudiation for all messages • Intended for gradual deployment

  23. Bibliography • Bellare, Mihir et al. Design, Implementation and Deployment of the iKP Secure Electronic Payment System. IEEE Journal of Selected Areas in Communications, VOL 18, NO. 4, April 2000. • Bellare, Mihir et al. iKP – A Family of Secure Electronic Payment Protocols. 1995.

More Related