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

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

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

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

지불결제 수단별 거래액 구성 비 (통계청, 2002. 2) 2001년 구분 ¾분기 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. 4 2. 1 -0. 3 1. 1 기타 1. 4 1. 2 1. 0 1. 1 -0. 3 -1. 5

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

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

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

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

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

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

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

SET의 목적 Payment Security n n confidentiality authentication integrity linkage Market Acceptance n n Interoperability n n between various vendors existing standards exportable technology any combination of H/W and S/W n 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의 지불정보 보안 Out-ofscope 인증기관 인증서 고객 Browser Wallet 인증서 1. 상품정보 2. 주문/지불정보 인증서 3. 지불정보 상인 상품 4. 지불승인 P G 대금 대금 on-line off-line SET 정의 암호화 X. 25 / 자체암호화 카드사 Host

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

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

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

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

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

3 -D Secure의 구조 (2) Customer 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 Acquirer Plug-in 5. Location of issuer’s Access Control Server sent to Merchant Plug-in 4. Issuer confirms card participation 3 -D Secure Access Control Server Issuer Visa Directory Visanet Payment Gateway Acquirer

3 -D Secure의 구조 (3) Active Merchant 3 -D Secure Merchant Plug-in Customer Merchant 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 Issuer Visanet Payment Gateway Acquirer

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

SPA의 구조 (1) 3. SPA Applet requests authentication information from the user Customer SPA Applet 1. SPA Applet detects SPA-enabled merchant page 2. SPA Applet reads information from merchant’s websites Merchant Acquirer Plug-in 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 Issuer Banknet Payment Gateway Acquirer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

참고문헌 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 (e. PSO), Institute for Prospective Technological Studies, July 2001. Gpayments Pty Ltd. , Visa 3 -D Secure vs. Master. Card 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 v 1. 0. 1, 2001.