전자지불시스템의 평가 및 전망
description
Transcript of 전자지불시스템의 평가 및 전망
전자지불시스템의 평가 및 전망
송용욱연세대학교 경영 · 정보학부
목차
인터넷 신용카드 지불시스템인터넷 계좌이체 시스템전자현금결제 시장의 미래신형 전자지불시스템 구조
기본 개념
“ 주문정보와 지불정보의 분리” Off-line 결제 – 통합 Green Commerce Model – 물리적 분리 SSL 기반 시스템 – 통합 SET – 논리적 분리 SDT, 3D-Secure, SPA – 물리적 분리
지불결제 수단별 거래액 구성비 ( 통계청 , 2002.2)
구분2001 년
전분기대비 증감
전년동분기대비 증감
¾ 분기 11 월 12 월 4/4분기
계 100.0 100.0 100.0 100.0 - -
온라인입금 27.8 26.1 26.6 26.8 -1.0 -5.3
신용카드 68.4 70.8 70.0 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/MasterCard)3-D Secure (Visa)Secure Payment Application (Master Card)
Green Commerce Server
Buyer Merchant
Credit Card Company
RealBank
goods
messages messages
Green Commerce Model
Encryption SummaryAlice’s Computer
PROPERTYEncrypt
Alice’s PrivateSignature Key
DigitalSignature
Alice’sCertificate
Bob’sCertificate
Encrypt
SymmetricKey
Encrypt
Bob’s PublicKey-Exchange
Key
EncryptedMessage
DigitalEnvelope
Bob’s Computer
DigitalEnvelope
Decrypt
Bob’s PrivateKey Exchange Key
EncryptedMessage
DigitalSignature
Decrypt
SymmetricKey
Decrypt
Alice’s PublicSignature Key
compare
Message Digest
Message Digest
Message Digest
1 2
3
4
7
8
6
10
9Message
5
EncryptedMessage
DigitalEnvelope
PROPERTYPROPERTY
Alice’sCertificate
SSL 기반 시스템
on-lineoff-line
대금
3. 지불정보
4. 지불승인
상품
고객Browser
상인
TTF
카드사
1. 상품정보2. 주문 /지불정보
대금
인증기관
SSL 용인증서
SSLX.25 / 자체암호화
SSL (Secure Socket Layer)
SSL
Handshake
Protocol
SSL
Handshake
Protocol
Server Certificate
Client Certificate
Encrypted secret key
Digital signature
Encrypted data with MAC
* MAC : Message Authentication Code
ServerClient
SSLRecordProtocol
SSLRecordProtocol
SSL 기반 시스템의 장단점
장점 단순 , 명료 개발 및 유지보수 용이 고객 사용 편리
웹 브라우저만 사용 인증서 자동 관리
단점 지불정보 ( 카드번호 , 계좌번호 , 비밀번호 , …) 가
상인에게 노출 보안성
DES key size = 40bits < 128bits RSA key size = 512bits < 1024bits
카드 소지자 인증의 문제
Secure Electronic Transaction
전자상거래에서 지불정보를 안전하고 비용효과적으로 처리할 수 있도록 규정한 프로토콜신용카드 기준VISA, Master
Version 1.0 - 1997 년 5 월 31 일 발표
SET 의 목적
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 의 지불정보 보안
on-lineoff-line
대금
3. 지불정보
4. 지불승인상품
상인 PG
1. 상품정보2. 주문 /지불정보
대금
인증기관
인증서
SET 정의 암호화X.25 / 자체암호화
카드사Host
인증서 인증서
Out-of-scope
고객Browser
Wallet
Dual Signature & Linkage
암호화
암호화
복호화
복호화
Digest
Digest
주문정보
지불정보
Digest 암호화 복호화+
Digest
Digest
암호화 복호화 Digest+
비교 ( 상인 )
암호화 복호화 Digest+
비교 ( 금융기관 )
KMB KM
V
KPB KP
V
KCV KC
B
KMB KM
V
KPB KP
V
KCV : 고객 개인키 KC
B : 고객 공개키KM
V : 상인 개인키 KMB : 상인 공개키
KPV : 금융기관 개인키 KP
B : 금융기관 공개키
SET 방식의 장단점
장점 지불정보가 상인에게 노출되지 않도록 이중 (dual)
으로 암호와 보안성 높음 (Key size 큼 , 인증 , 무결성 , …)
단점 시스템이 복잡해지고 시스템 부하가 큼 별도의 고객 S/W(Digital Wallet) 필요
사용 불편 ( 별도의 사용법 , Setup) 유지보수 어려움
3-D SET
SET 에서의 고객 S/W(Digital Wallet) 기능을 웹 서버에 올림으로써 고객 편리성 증대단점 상인 , PG, 인증 기관 시스템의 복잡성은
계속 남음 고객의 웹 브라우저와 고객 서버 간의
보안성의 문제
3-D SET 의 구조
on-lineoff-line
대금
3. 지불정보
4. 지불승인상품
상인
PG
1. 상품정보2. 주문 /지불정보
대금
인증기관
인증서
SET 정의 암호화X.25 / 자체암호화
카드사Host
인증서 인증서
Out-of-scope
Walle
tServer고
객
SSL
3-D Secure 의 구조 (1)
Customer
MerchantAcquirer Plug-in
Active Merchant
3-D SecureMerchant
Plug-in
Issuer
3-D SecureAccess Control
Server
Acquirer
PaymentGateway
VisaDirectory
Visanet
1. Customer enters details at merchant site
2. Merchant Plug-in checks card issuer participation with VISA
directory
3. VISA directory checks card participation with
issuer
3-D Secure 의 구조 (2)
Customer
MerchantAcquirer Plug-in
Active Merchant
3-D SecureMerchant
Plug-in
Issuer
3-D SecureAccess Control
Server
Acquirer
PaymentGateway
VisaDirectory
Visanet
6. Merchant Plug-in redirects customer’s browser to issuer’s
Access Control Server with transaction details
5. Location of issuer’s Access Control Server sent to Merchant
Plug-in
4. Issuer confirms card participation
3-D Secure 의 구조 (3)
Customer
MerchantAcquirer Plug-in
Active Merchant
3-D SecureMerchant
Plug-in
Issuer
3-D SecureAccess Control
Server
Acquirer
PaymentGateway
VisaDirectory
Visanet
7. Issuer’s Access Control Server requests
username and password from customer
8. Customer presents password into issuer
system
9. Issuer’s Access Control Server validates
password, signs response and redirects customer to
Merchant Plug-in
3-D Secure 의 구조 (4)
Customer
MerchantAcquirer Plug-in
Active Merchant
3-D SecureMerchant
Plug-in
Issuer
3-D SecureAccess Control
Server
Acquirer
PaymentGateway
VisaDirectory
Visanet
14. Merchant confirms transaction and issues receipt
to customer
10. Merchant submits normal
transaction to acquirer
11. Acquirer sends authorization requests to issuer via Visanet
12. Issuer sends authorization response to acquire via Visanet
13. Acquirer sends
transaction response back to merchang
SPA 의 구조 (1)
MerchantAcquirer Plug-in
Issuer
SPAServer
Acquirer
PaymentGateway
Banknet
1. SPA Applet detects SPA-enabled merchant page
4. SPA Applet sends authentication and
transaction information to
issuer’s SPA Server
3. SPA Applet requests authentication
information from the userCustom
erSPA Applet 2. SPA Applet reads information from
merchant’s websites
5. Issuer SPA Server sends authentication
token back to SPA Applet
SPA 의 구조 (2)
MerchantAcquirer Plug-in
Issuer
SPAServer
Acquirer
PaymentGateway
Banknet
6. SPA Applet embeds the authentication token in the merchant’s site and optionally fills the online
form
7. Merchant sends authorization request and
authentication token to acquirer
Customer
SPA Applet 11. Merchant confirms transaction and issues receipt to customer
10. Acquirer sends transaction
response back to merchant
8. Acquirer sends authorization request and authentication token to issuer via Banknet
9. Issuer sends authorization response to acquirer
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, …
인터넷 계좌이체 시스템
SSL 기반 시스템Screen Scraping 기반 시스템SDT
SSL 기반 시스템
on-lineoff-line
3. 지불정보
4. 계좌이체상품
고객Browser
상인
TTF은행
1. 상품정보2. 주문 /지불정보
4. 계좌이체
인증기관
SSL 용인증서
SSLX.25 / 자체암호화
Screen Scraping 기반 시스템
인터넷 뱅킹 시스템 이용Screen scraping 기법 적용인터넷 뱅킹 시스템 변경 시 Screen scraping S/W 의 Update 필요인터넷 뱅킹 시스템에만 적용 가능
SDT 의 지불정보 보안
5. 이체통보
상품
1. 상품정보2. 주문정보
고객
WebBrowser
상인
고객은행
4. 대금 ( 이체 )대금3. 지불정보
상인은행
대금
인증기관
인증서
인증서
on-lineoff-line
SSL (128 bits)SDT 정의 암호화
기존 은행망
SSL 인증서
SDT 의 보안 목표
기밀성 지불정보
인증 고객 인증 고객은행 인증 상인 인증
무결성 지불정보 이체통보
SDT 의 특징
단순 , 명료개발 및 유지보수 용이고객 사용 편리 ( 웹 브라우저만 사용 )
보안성 높음 (key size = 128 bits)
지불정보가 상인에게 노출되지 않음직불 외에 신용카드 지불 등에도 수정 없이 사용가능
SDT 사용상의 이점
사용자 입장 자신의 지불 정보가 상인에게 전달되지 않으므로
지불 정보 보안에 좀 더 확신을 가질 수 있음상인 입장 고객의 지불 정보를 자신이 직접 다루지 않으므로
지불 정보 관련 사고 발생시 책임회피 가능금융기관 입장 개별 금융기관별로 고객 인증을 위한 나름대로의
방법 적용 가능 . 따라서 , 사고 발생의 소지를 줄일 수 있음
SI 업체 표준 Solution 개발 및 판매 가능
SCT, SMT, SQT, …
SDT (Secure Debit Transation) 직불
SCT (Secure Credit Transaction) 신용카드 , 후불
SMT (Secure Money Transaction 전자현금
SQT (Secure Cheque Transaction) 수표 , 어음
SCT 의 지불정보 보안
4. 승인통보
상품
1. 상품정보2. 주문정보
고객
WebBrowser
상인
고객카드사
대금대금3. 지불정보
상인은행
대금
인증기관
인증서
인증서
on-lineoff-line
SSL (128 bits)SCT 정의 암호화
기존 은행망
SSL 인증서 5. Capture
전자현금
IC Card 형 / 네트워크 형Coin 형 / 총액형DigiCash 새로운 화폐 발행
충전형 서버 기반 전자현금
충전형 전자현금 시스템 구조
5. 결제통보
상품
1. 상품정보2. 주문정보
고객
WebBrowser
상인
전자현금서버
4. 대금 ( 이체 )대금충전3. 지불정보
상인은행
대금
on-lineoff-line
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 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
신형 전자지불시스템 구조
“ 결제 사고는 인증의 문제”다양한 지불수단 간 동일한 지불 시스템 구조 필요 신용카드 : 3-D Secure, SPA 계좌이체 : SDT 전자현금 : 충전형 서버 기반 전자현금
주문정보와 지불정보의 분리한국형 표준의 확립 필요
주문정보와 지불정보의 분리
5. 결제통보
상품
1. 상품정보2. 주문정보
고객
WebBrowser
상인
금융기관TTF /Host
4. 대금 ( 이체 )대금3. 지불정보
상인은행
대금
인증기관
인증서
인증서
on-lineoff-line
SSL (128 bits)SDT 정의 암호화
기존 은행망
SSL 인증서
참고문헌
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.