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

Presentation on theme: "전자지불시스템의 평가 및 전망 송용욱 연세대학교 경영·정보학부."— Presentation transcript:

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

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

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

4 지불결제 수단별 거래액 구성비 (통계청, 2002.2) 구분 2001년 ¾분기 11월 12월 계 100.0 - 온라인입금
전분기대비 증감 전년동분기대비 증감 ¾분기 11월 12월 4/4분기 계 100.0 - 온라인입금 27.8 26.1 26.6 26.8 -1.0 -5.3 신용카드 68.4 70.8 70.0 1.6 5.7 전자화폐 2.4 1.9 2.1 -0.3 1.1 기타 1.4 1.2 1.0 -1.5

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 Green Commerce Model Green Commerce Server Buyer Merchant
Credit Card Company Real Bank goods messages

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

8 SSL 기반 시스템 인증기관 고객 상인 TTF 카 드 사 on-line SSL off-line X.25 / 자체암호화 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 = bits < 128bits RSA key size = bits < 1024bits 카드 소지자 인증의 문제

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

12 SET의 목적 Payment Security Interoperability Market Acceptance
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

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

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

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

16

17

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

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

20 3-D Secure의 구조 (1) Merchant Customer Issuer Acquirer Visa Directory
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) Merchant Customer Issuer Acquirer Visa Directory
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 8. Customer presents password into issuer system
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) Merchant Customer Issuer Acquirer Visa Directory
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) Customer Merchant Issuer Acquirer SPA Server Payment
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) Customer Merchant Issuer Acquirer SPA Server Payment
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)
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 기반 시스템 인증기관 고객 상인 TTF 은행 on-line SSL off-line X.25 / 자체암호화 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. 상품정보 인증서 고객 상인 인증기관 2. 주문정보 상품 SSL 인증서 인증서 5. 이체통보 대금
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. 상품정보 인증서 고객 상인 인증기관 2. 주문정보 상품 SSL 인증서 인증서 4. 승인통보
Web Browser 상인 인증기관 2. 주문정보 상품 SSL 인증서 인증서 4. 승인통보 5. Capture 대금 3. 지불정보 고객카드사 상인은행 대금 대금 on-line SSL (128 bits) 기존 은행망 off-line SCT 정의 암호화

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

37 충전형 전자현금 시스템 구조 1. 상품정보 고객 상인 2. 주문정보 상품 5. 결제통보 대금 3. 지불정보 전자현금서버
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. 상품정보 인증서 고객 상인 인증기관 2. 주문정보 상품 SSL 인증서 인증서 5. 결제통보
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.