전자지불시스템의 평가 및 전망

1. 전자지불시스템의 평가 및 전망 송용욱 연세대학교 경영·정보학부

2. 목차 • 인터넷 신용카드 지불시스템 • 인터넷 계좌이체 시스템 • 전자현금 • 결제 시장의 미래 • 신형 전자지불시스템 구조

3. 기본 개념 • “주문정보와 지불정보의 분리” • Off-line 결제 – 통합 • Green Commerce Model –물리적 분리 • SSL 기반 시스템 – 통합 • SET – 논리적 분리 • SDT, 3D-Secure, SPA – 물리적 분리

4. 지불결제 수단별 거래액 구성비 (통계청, 2002.2)

5. 인터넷 신용카드 지불시스템 • Green Commerce Model (First Virtual) • SSL 기반 시스템 • Secure Electronic Transaction (Visa, Master Card) • 3-D SET (Visa, Eurocard/MasterCard) • 3-D Secure (Visa) • Secure Payment Application (Master Card)

6. Credit Card Company Real Bank Green Commerce Server messages messages Buyer goods Merchant Green Commerce Model

7. Bob’s Computer Alice’s Computer Bob’s Private Key Exchange Key 1 2 Alice’s Private Signature Key PROPERTY Decrypt Encrypt Digital Signature Digital Envelope 6 Message Digest 5 9 Message PROPERTY PROPERTY Message Digest 3 7 Decrypt Encrypted Message Symmetric Key Encrypt Symmetric Key Encrypted Message Encrypted Message 10 Alice’s Certificate Alice’s Certificate Digital Envelope compare 4 8 Bob’s Certificate Encrypt Decrypt Message Digest Digital Envelope Digital Signature Bob’s Public Key-Exchange Key Alice’s Public Signature Key Encryption Summary

8. SSL 기반 시스템 인증기관 SSL용 인증서 1. 상품정보 3. 지불정보 고객 Browser 상인 TTF 카 드 사 2. 주문/지불정보 4. 지불승인 상품 대금 대금 on-line SSL off-line X.25 / 자체암호화

9. SSL (Secure Socket Layer) Client Server Server Certificate SSL Handshake Protocol SSL Handshake Protocol Client Certificate Encrypted secret key Digital signature SSL Record Protocol SSL Record Protocol Encrypted data with MAC * MAC : Message Authentication Code

10. SSL 기반 시스템의 장단점 • 장점 • 단순, 명료 • 개발 및 유지보수 용이 • 고객 사용 편리 • 웹 브라우저만 사용 • 인증서 자동 관리 • 단점 • 지불정보(카드번호, 계좌번호, 비밀번호, …)가 상인에게 노출 • 보안성 • DES key size = 40bits < 128bits • RSA key size = 512bits < 1024bits • 카드 소지자 인증의 문제

11. Secure Electronic Transaction • 전자상거래에서 지불정보를 안전하고 비용효과적으로 처리할 수 있도록 규정한 프로토콜 • 신용카드 기준 • VISA, Master • Version 1.0 - 1997년 5월 31일 발표

12. Payment Security confidentiality authentication integrity linkage Interoperability between various vendors existing standards exportable technology any combination of H/W and S/W Market Acceptance ease of implementation minimal impact on merchant, acquirer, and payment system applications and infrastructure minimize change to the relationship between acquirers and merchants, and cardholders and issuers SET의 목적

13. SET의 지불정보 보안 Out-of-scope 인증기관 인증서 인증서 인증서 1. 상품정보 고객 Browser Wallet 상인 P G 카드사 Host 3. 지불정보 2. 주문/지불정보 4. 지불승인 상품 대금 대금 on-line SET 정의 암호화 off-line X.25 / 자체암호화

14. KMB KMV 암호화 복호화 주문정보 KMB KMV + 암호화 복호화 KCV KCB 비교 (상인) + 암호화 복호화 Digest 비교 (금융기관) 암호화 복호화 Digest Digest Digest Digest Digest + 지불정보 KPB KPV 암호화 복호화 Digest KPB KPV Dual Signature & Linkage KCV : 고객 개인키 KCB : 고객 공개키 KMV : 상인 개인키 KMB : 상인 공개키 KPV : 금융기관 개인키 KPB : 금융기관 공개키

15. SET 방식의 장단점 • 장점 • 지불정보가 상인에게 노출되지 않도록 이중(dual)으로 암호와 • 보안성 높음 (Key size 큼, 인증, 무결성, …) • 단점 • 시스템이 복잡해지고 시스템 부하가 큼 • 별도의 고객 S/W(Digital Wallet) 필요 • 사용 불편 (별도의 사용법, Setup) • 유지보수 어려움

18. 3-D SET • SET에서의 고객 S/W(Digital Wallet) 기능을 웹 서버에 올림으로써 고객 편리성 증대 • 단점 • 상인, PG, 인증 기관 시스템의 복잡성은 계속 남음 • 고객의 웹 브라우저와 고객 서버 간의 보안성의 문제

19. 3-D SET의 구조 Out-of-scope 인증기관 인증서 인증서 인증서 1. 상품정보 고객 상인 P G 카드사 Host 3. 지불정보 2. 주문/지불정보 Wallet Server 4. 지불승인 상품 대금 대금 on-line SET 정의 암호화 SSL off-line X.25 / 자체암호화

20. 3-D Secure의 구조 (1) 1. Customer enters details at merchant site Active Merchant 3-D Secure Merchant Plug-in Merchant Customer Acquirer Plug-in 2. Merchant Plug-in checks card issuer participation with VISA directory 3. VISA directory checks card participation with issuer Visa Directory 3-D Secure Access Control Server Payment Gateway Visanet Issuer Acquirer

21. 3-D Secure의 구조 (2) 6. Merchant Plug-in redirects customer’s browser to issuer’s Access Control Server with transaction details Active Merchant 3-D Secure Merchant Plug-in Merchant Customer Acquirer Plug-in 5. Location of issuer’s Access Control Server sent to Merchant Plug-in 4. Issuer confirms card participation Visa Directory 3-D Secure Access Control Server Payment Gateway Visanet Issuer Acquirer

22. 3-D Secure의 구조 (3) Active Merchant 3-D Secure Merchant Plug-in Merchant Customer Acquirer Plug-in 7. Issuer’s Access Control Server requests username and password from customer 8. Customer presents password into issuer system Visa Directory 9. Issuer’s Access Control Server validates password, signs response and redirects customer to Merchant Plug-in 3-D Secure Access Control Server Payment Gateway Visanet Issuer Acquirer

23. 3-D Secure의 구조 (4) 14. Merchant confirms transaction and issues receipt to customer Active Merchant 3-D Secure Merchant Plug-in Merchant Customer Acquirer Plug-in 13. Acquirer sends transaction response back to merchang 10. Merchant submits normal transaction to acquirer Visa Directory 11. Acquirer sends authorization requests to issuer via Visanet 3-D Secure Access Control Server Payment Gateway Visanet Issuer Acquirer 12. Issuer sends authorization response to acquire via Visanet

24. SPA의 구조 (1) 3. SPA Applet requests authentication information from the user 1. SPA Applet detects SPA-enabled merchant page Customer Merchant SPA Applet Acquirer Plug-in 2. SPA Applet reads information from merchant’s websites 4. SPA Applet sends authentication and transaction information to issuer’s SPA Server 5. Issuer SPA Server sends authentication token back to SPA Applet SPA Server Payment Gateway Banknet Issuer Acquirer

25. SPA의 구조 (2) 6. SPA Applet embeds the authentication token in the merchant’s site and optionally fills the online form Customer Merchant SPA Applet Acquirer Plug-in 11. Merchant confirms transaction and issues receipt to customer 7. Merchant sends authorization request and authentication token to acquirer 10. Acquirer sends transaction response back to merchant 8. Acquirer sends authorization request and authentication token to issuer via Banknet SPA Server Payment Gateway Banknet Issuer Acquirer 9. Issuer sends authorization response to acquirer

26. 3-D Secure vs. SPA (Gpayments Pty Ltd, 2002) • 3-D Secure • Centralized structure • Visa directory • Denial-of-service attack • Merchant is pivotal • Authentication and authorization is separated • Web-browser only • Some problems for chip and mobile purchasing • “man-in-the-middle” attack • PAM (Personal Assurance Message) • Authentication for each purchase • Authentication History server • Data mining • First-mover advantage • SPA • Distributed payment architecture • Open infrastructure • Issuer is pivotal • Authentication and authorization as a single process • Java Applet • Downloading • Security of Java Applet • Automatic form filling • Authentication for multiple purchases • Diverse services for cardholders • Receipt capture, online transaction reporting, loyalty point reporting, merchant site links, storage of passwords, …

27. 인터넷 계좌이체 시스템 • SSL 기반 시스템 • Screen Scraping 기반 시스템 • SDT

28. SSL 기반 시스템 인증기관 SSL용 인증서 1. 상품정보 고객 Browser 상인 TTF 은행 3. 지불정보 2. 주문/지불정보 4. 계좌이체 상품 4. 계좌이체 on-line SSL off-line X.25 / 자체암호화

29. Screen Scraping 기반 시스템 • 인터넷 뱅킹 시스템 이용 • Screen scraping 기법 적용 • 인터넷 뱅킹 시스템 변경 시 Screen scraping S/W의 Update 필요 • 인터넷 뱅킹 시스템에만 적용 가능

30. SDT의 지불정보 보안 1. 상품정보 인증서 고객 Web Browser 상인 인증기관 2. 주문정보 상품 SSL 인증서 인증서 5. 이체통보 대금 3. 지불정보 고객은행 상인은행 4. 대금(이체) 대금 on-line SSL (128 bits) 기존 은행망 off-line SDT 정의 암호화

31. SDT의 보안 목표 • 기밀성 • 지불정보 • 인증 • 고객 인증 • 고객은행 인증 • 상인 인증 • 무결성 • 지불정보 • 이체통보

32. SDT의 특징 • 단순, 명료 • 개발 및 유지보수 용이 • 고객 사용 편리 (웹 브라우저만 사용) • 보안성 높음 (key size = 128 bits) • 지불정보가 상인에게 노출되지 않음 • 직불 외에 신용카드 지불 등에도 수정 없이 사용가능

33. SDT 사용상의 이점 • 사용자 입장 • 자신의 지불 정보가 상인에게 전달되지 않으므로 지불 정보 보안에 좀 더 확신을 가질 수 있음 • 상인 입장 • 고객의 지불 정보를 자신이 직접 다루지 않으므로 지불 정보 관련 사고 발생시 책임회피 가능 • 금융기관 입장 • 개별 금융기관별로 고객 인증을 위한 나름대로의 방법 적용 가능. 따라서, 사고 발생의 소지를 줄일 수 있음 • SI 업체 • 표준 Solution 개발 및 판매 가능

34. SCT, SMT, SQT, … • SDT (Secure Debit Transation) • 직불 • SCT (Secure Credit Transaction) • 신용카드, 후불 • SMT (Secure Money Transaction • 전자현금 • SQT (Secure Cheque Transaction) • 수표, 어음

35. SCT의 지불정보 보안 1. 상품정보 인증서 고객 Web Browser 상인 인증기관 2. 주문정보 상품 SSL 인증서 인증서 4. 승인통보 5. Capture 대금 3. 지불정보 고객카드사 상인은행 대금 대금 on-line SSL (128 bits) 기존 은행망 off-line SCT 정의 암호화

36. 전자현금 • IC Card 형 / 네트워크 형 • Coin 형 / 총액형 • DigiCash • 새로운 화폐 발행 • 충전형 서버 기반 전자현금

37. 충전형 전자현금 시스템 구조 1. 상품정보 고객 Web Browser 상인 2. 주문정보 상품 5. 결제통보 대금 3. 지불정보 전자현금서버 상인은행 4. 대금(이체) 대금충전 on-line SSL (128 bits) 기존 은행망 off-line SDT 정의 암호화

38. 결제 시장의 미래 (by IPTS) • Pre-history (1976~1992) • Pioneer Phase (1993~1995) • “Roll back forward” (1995~1998) • The Second Wave (1999~2001) • A Paradigm shift • Front-end • Customers and merchants are liberated from complex payment software • Software requirements are reduced to a minimum and substituted by access to a central server (payment host) • Back-end • The central payment server is able to host many payment schemes and to offer added value

39. 신형 전자지불시스템 구조 • “결제 사고는 인증의 문제” • 다양한 지불수단 간 동일한 지불 시스템 구조 필요 • 신용카드 : 3-D Secure, SPA • 계좌이체 : SDT • 전자현금 : 충전형 서버 기반 전자현금  • 주문정보와 지불정보의 분리 • 한국형 표준의 확립 필요

40. 주문정보와 지불정보의 분리 1. 상품정보 인증서 고객 Web Browser 상인 인증기관 2. 주문정보 상품 SSL 인증서 인증서 5. 결제통보 대금 3. 지불정보 금융기관 TTF / Host 상인은행 4. 대금(이체) 대금 on-line SSL (128 bits) 기존 은행망 off-line SDT 정의 암호화

41. 참고문헌 • Bohle, K., "The Potential of Server-based Internet Payment Systems - An Attempt to Assess the Future of Internet Payments," Background Paper No. 3, Electronic Payment Systems Observatory (ePSO), Institute for Prospective Technological Studies, July 2001. • Gpayments Pty Ltd., Visa 3-D Secure vs. MasterCard SPA – A comparison of online authentication standards, 2002. • Master Card and Visa, Secure Electronic Transaction Specification Version 1.0, May 1997. • Visa, 3-D Secure: Protocol Specification - Core Functions v1.0.1, 2001.