Transcript 제10장 전자상거래보안
정보 보호 응용
10. 전자상거래 보안 e-commerce security
충북대 네트워크 보안 연구실
[ jinmun @ gmail.com ]
개요 (1)
전자지불 프로토콜의 필요성
전자상거래(e― commerce, m― commerce)에서의 물품구매에 따 른 결제 수단이 필요
전자지불 프로토콜의 종류
전자화폐 안정성, 이중사용방지,익명성,프라이버시보호,전자현금의 분 할 사용등의 사항이 최대한 보장 카드결제 프로토콜 소액지불 프로토콜 거액거래에 요구되는 정도의 안전성은 필요하지 않음 소액에 적합한 안전성보장과 빠른 속도의 효율성 필요 계산량 감소가 필요하고, 통신양 감소 필요 전자수표
2007-01
정보보호응용 2
개요 (2)
전자상거래 지불 시스템 신용카드 기반 전자화폐 기반 보안프로토콜 • S-HTTP • SSL • TLS • 기타 지불프로토콜 소액지불 프로토콜 • SET • Non-SET - CyberCash - FirstVirtual - 기타 • NetBill • 기타 웹 기반 웹 연동, 전자지갑 웹 연동, 전자지갑, 스마트카드 오프라인방식, 스마트카드, 오프라인 단말기 전자화폐 프로토콜 • Mondex • Ecash • 기타
2007-01
정보보호응용 3
전자화폐 (1)
개요
전자상거래 수행에 필수적으로 요구되는 기술 공개된 통신망을 통해 다자간이 자신의 비밀은 노출하지 아니하고 상대방에게 비밀의 소유 사실을 납득시키는 방법이 필요 Blind signature, zero-knowledge, bit commitment 등
Blind signature
1983년 David Chaum에 의해 제안 RSA Signature를 기반으로 서명하고자 하는 문서의 내용을 비밀 로 유지하고자 할때 사용 전자화폐에서 은행에 의한 개인의 정보와 화폐사용처를 추적하는 것을 방지
2007-01
정보보호응용 4
전자화폐 (2)
Blind signature 프로토콜 user α∈ R {1,n} t = m
α e mod n
t bank S’ = t
d mod n = (
mα e ) d mod n S
’
S = S
’
/α mod n t d = (mα e ) d mod n t d /α = m d α/
α =m
d mod n m : message α : blind factor e : bank’s public key d : bank’s private key
2007-01
정보보호응용 5
전자화폐 (3)
전자화폐의 기본 구성 요소
은행 ①인출단계 ③예치단계 상점 고객 ②지불단계
2007-01
정보보호응용 6
전자화폐 (4)
전자화폐 기본 프로토콜
인출 프로토콜 (withdrawal protocol) 사용자와 은행 사이에서 수행되는 프로토콜 은행이 사용자에게 전자화폐를 발급해 주는 절차를 명세한 것 전자화폐 시스템 설계할 때 가장 중요한 부분 지불 프로토콜(payment protocol) 사용자와 상점 사이에서 수행되는 프로토콜 사용자가 구매대금으로 자신의 전자화폐를 상점에 지불하는 과정을 명세 예치 프로토콜(deposit protocol) 상점과 은행 사이에서 수행되는 프로토콜 상점이 사용자로부터 받은 전자화폐를 은행이 결제
2007-01
정보보호응용 7
전자화폐 (5)
On-line System
결제단계가 이루어지기 전에 은행의 데이타베이스를 검색 지불과 결제가 일괄적으로 처리됨 사용되는 현금의 이중사용여부를 확인 매 결제단계마다 상점이 은행과 연결
Off-line System
Smart card 등을 이용하여 지불만 수행 지불 후 상점에 의한 결제 프로토콜은 따로 수행 지불과 결제가 동시에 수행되지 않으므로 이중사용방지 기법이 필 요
2007-01
정보보호응용 8
전자화폐 (6)
전자화폐 위협요소
위조(Forgery) : 은행을 제외한 참가자가 인출 프로토콜에 참가한 후에 인출한 전자현금의 금액을 액면가에 초과하는 전자현금으로 바꾸어 그것이 은행에 의해 유효하게 받아들여지게 하는 공격 이중사용(Double spending) : 사용자가 발급받은 전자현금을 한번 이상 사용하는 행위 초과사용(Over spending) : 사용자가 발급받은 액면가 이상의 금 액을 사용하는 행위 위장(Impersonation) : 공격자가 마치 사용자인 것처럼 사용자의 계좌에 접근하여 돈을 가로채는 공격 돈세탁(Money laundering) : 불법적인 돈의 출처를 감추기 위하여 행해지는 이체
2007-01
정보보호응용 9
전자화폐 (7)
불법구매 (Illegal purchases) : 마약의 구매와 같은 불법적인 물품 구매 약탈(Blackmail) : 공격자가 사용자에게 사용자의 계좌 에서 돈을 인출할 것을 강요하고 공격자가 추적당하지 않고 돈을 입금시키거 나 사용할 수 있는 방법으로 공격자에게 돈을 전송하도록 하는 공 격 은행강탈(Bank robbery) : 공격자들의 집단이 은행에게 추후 사용 할 수 있는 돈을 얻도록 프로토콜에 참여하기를 강요하는 공격
2007-01
정보보호응용 10
전자화폐 (8)
기본적인 요구사항
이중사용방지(double spending prevention) : 오프라인 전자화폐 는 사용자가 같은 코인을 두 번 사용할 수 없어야 함 익명성(anonymity) :실물화폐와 마찬가지로 은행이 신뢰기관의 협 조없이 전자화폐와 정직한 사용자의 신원을 연결시키는 것을 불가 능하게 해야 함 추적불가능성(untraceability):전자현금과 사용자 사이의 관계는 권 한이 부여된 익명성 취소의 경우를 제외하고는 은행이 추적하지 못하도록 해야 함 완전정보화 :모든 정보는 디지털화 되어있어 비트의 기본요소로 구 성 위조 불가능성(unforgeability) :은행과 같이 권한이 부여된 참가자 만이 전자현금을 발행할 수 있어야 함
2007-01
정보보호응용 11
전자화폐 (9)
추가적인 요구사항
분할성(divisiability): 먼저 정확한 금액의 지불을 위하여 전자현금 의 액면금액에 대해서 더 작은 단위로 나누어질 수 있어야 함 양도성(transferability): 한번 인출된 전자현금이 다른 사용자에게 양도가 가능해야 함 연결불가능성(unlinkability): 동일 사용자가 사용한 서로 다른 전자 현금과의 연결 불가 공정성(fairness): 사용자는 신뢰기관과 은행에 대해서 각각 익명 성이 보장되어야 하는데, 이 두 기관의 합법적인 협조에 의해서만 익명성이 조건적으로 철회될 수 있어야 함 사용자 추적(user-tracing): 은행과 신뢰기관은 사용된 전자현금과 사용자를 연결 현금추적(coin-tracing): 사용될 전자현금과 예치된 전자현금과 관 련된 정보가 일치하는지를 계산가능 해야 함
2007-01
정보보호응용 12
전자화폐 (10)
초과사용 추적(overspent-tracing) 오프라인 전자화폐에서 이중 사용 이외에도 초과사용이 가능 할 수도 있기 때문에 은행은 전자현금을 초과 사용한 사용자 의 신분을 알 필요가 있음 효율성(efficiency) 전자화폐가 실용적으로 사용되기 위해서는 저장용량, 통신량, 계산량에 있어서 효율적이어야 함
2007-01
정보보호응용 13
NetBill (1)
CMU에서 개발한 지불시스템으로 주로 저가의 정보상품 및 소프트웨어 구매와 판매에 적합하게 설계됨.
은행 구매자가 어떤 정보상품 을 구입하게 되면 NetBill 서버의 구매자 계좌에서 해당 액수만큼 출금이 되고 동시에 판 매자 계좌에 그 액수가 입금된다.
구매인 Network NetBill Server 지불 방식은 전자수표에 기반 판매자
2007-01
정보보호응용 14
NetBill (2)
1.
구매자는 구매요청서를 판매자에게 보낸다.
2.
판매자는 견적서를 구매자에게 보낸다.
3.
구매자가 판매자에게 구매 요청을 한다.
4.
판매자는 암호화된 정보와 무결성을 보장하는 해쉬 값을 구매자에게 보낸다. 5.
구매자는 자신이 계산한 해쉬 값과 판매자가 보낸 해쉬 값이 일치하는 지를 확인함으로써 자신이 요청한 정보가 정확히 수신되었다는 것을 확인한다. 구매자는 자신이 디지털 서명한 전자 지불요청서를 판매자 에게 보낸다.
6.
판매자는 이것을 NetBill 서버에 보내어 구매자의 계좌가 유효한지 확 인한다. NetBill 서버로부터의 승인이 떨어지면 판매자는 자신이 암호 화한 정보를 복호화 할 수 있는 키를 구매자에게 전달한다.
2007-01
정보보호응용 15
구매자 NetBill 서버
NetBill (3)
가격 요청 1 2 3 4 5 8 상품 인도 지불
2007-01
정보보호응용 판매자 6 7 16
NetBill : 가격요청
구매자
ticket
cm
,
E
k cm
(
product
1
_
request
_
data
,
TID
,...)
2 판매자
E
k cm
(
price
,
TID
,...)
1. 구매자가 특정 정보상품의 구입을 결정하였으면 티켓과 구 매요청서를 판매자에게 보낸다.
2. 판매자는
ticket cm
으로부터 대칭키
k cm
을 구하여 구매 요청 서를 복호화 한다. 판매자는 price와 TID를 암호화하여 구 매자에게 보낸다.
Product_request_data : 구매자가 요청하는 상품 TID : 거래 식별번호
2007-01
정보보호응용 17
NetBill : 상품인도
구매자
ticket
cm
,
3
E
k cm
(
TID
)
판매자 4
E
k Goods
(
Goods
),
E
k cm
(
h
(
E
k Goods
(
Goods
))),
EPOID
3. 구매자는 암호화된 TID를 보내 구매의사를 표시한다.
(이 시점에서 거래를 취소할 수 없음) 4. 판매자는 임의로 생성한 대칭키
k Goods
로 암호화하여 구매자에게 보낸다. 를 이용하여 정보상품 Goods 를 암호화하고 또한 암호화된 정보상품을 공개된 해쉬함수 SHA를 통해 해쉬 값을 구하여 이것 역시 상호간에 공유된 대칭키
k cm
으 EPOID (electronic payment order ID): NetBill 데이터베 이스에서 거래를 식별하기 위하여 사용되는 값
2007-01
정보보호응용 18
NetBill : 지불프로토콜
구매자
ticket cm
,
E k cm
(
EPO
,
5
Signature C
)
판매자 8
E k cm
(Re
ceipt
),
E k Cn
(
EPOID
,
cAccount
,
Balance
,...)
NetBill 서버 6
ticket
mn
,
E
k mn
(
EPO
,
Signature
C
),
mAccount
,
k
Goods
,
Signature
m
) 7
E
k mn
(Re
ceipt
),
E
k cn
(
EPO
,
cAccount
,
Balance
,...)
2007-01
정보보호응용 19
구매자
NetBill : 지불프로토콜-1
ticket
cm
,
E
k cm
(
EPO
,
Signature
C
)
5 판매자 5. 구매자는 전자 지불요청서 EPO를 작성하여 여기에 자신의 디지털 서명을 첨가한 후에 티켓과 함께 판매자에게 보낸다.
EPO는 두 부분으로 구성 됨 • 판매자와 NetBill 서버가 모두 읽을 수 있는 내용 --- 구매자 ID, 상품가격, 판매자 ID등 • NetBill 서버만 읽을 수 있는 내용 --- 구매자와 서버간에 공유 된 대칭키
k cn
으로 암호화된 지불관련 내용들, 즉 구매자의 신 원을 증명하는 티켓, 구매자 계좌번호 등
2007-01
정보보호응용 20
SET의 개요 (1)
SET의 개념
SET(Secure Electronic Transaction)은 안전한 지급결제수단을 제공하기 위하여 비자와 마스터카드사가 공동으로 개발한 신용/ 직불카드결제용 전문 및 보안 프로토콜 기술지원사 GTE, IBM, Microsoft, Netscape, SAIC, Terisa, Verisign '96.
6.17 : 초안 발표 ( '97. 5.31일 버전 1.0 발표 ) 상호운용성 보장 : SET을 적용한 각 사의 제품간 상호운용성 보장 을 위 하 여 SET 적 용 제 품 은 SAIC(Science Applications International Corporation)에서 테스트 및 인증을 거치도록 하고 있음
2007-01
정보보호응용 21
SET의 개요 (2)
SET에서의 보안 서비스
기밀성(Confidentiality) : 통신회선상의 비밀정보 암호화 기능 무결성(Integrity) : 통신회선상의 정보변질여부 확인 기능 인증(Authentication) : 통신 상대방의 정당성 확인 기능 부인봉쇄(Non-Repudiation) : 통신 상대방간 송 · 수신 사실부인 방 지기능
2007-01
정보보호응용 22
SET의 구성요소 (1)
2007-01
정보보호응용 23
SET의 구성요소 (2)
고객(Cardholder) : 인터넷쇼핑몰에서 물품 또는 서비스를 구매하는 자 판매자(Merchant) : 인터넷상에서 상품이나 서비스를 제공하는자 발급사(Issuer) : 고객의 카드발급 금융기관 혹은 결제카드 소지인의 계좌가 개설되어 있는 금융기관 매입사(Acquirer) : 판매자의 가맹점 승인 금융기관 혹은 판매자의 계 좌가 개설되어 있는 금융기관 지급정보 중계기관(Payment Gateway) : 판매자가 요청한 고객의 지급 정보로 해당 금융기관에 승인 및 결제를 요청하는 기관 인증기관(Certification Authority) : 고객 및 판매자 등 각 참여기관이 인터넷 상에서 서로 신뢰하면서 거래할 수 있도록 각 참여기관에게 전 자적인 인증서를 발급하는 기관
2007-01
정보보호응용 24
SET의 보안기술 (1)
기본 암호기술
비밀키 암호방식(대칭키 암호방식) 공개키 암호방식(비대칭키 암호방식) 전자봉투(Digital Envelope) 전자서명(Digital Signature)
SET의 보안 프로토콜
사용 Key 종류 기본 프로토콜 이중서명(Dual Signature) 프로토콜 인증서(Certificate) 이용 프로토콜
2007-01
정보보호응용 25
SET의 보안기술 (2)
비밀키 암호방식(대칭키 암호방식)
비교적 구현이 용이하고 실행속도가 빠른편 키 분배 및 관리가 어렵고 거래쌍방이 동일한 키를 사용하는 관계로 송수 신 부인시 해결책이 없음
2007-01
정보보호응용 26
SET의 보안기술 (3)
공개키 암호방식(비대칭키 암호방식)
수신자의 공개키로 암호화하는 경우 수신자 이외에는 암호문을 해독할 수 없으므로 전송 메시지의 기밀성이 보장됨
2007-01
정보보호응용 27
SET의 보안기술 (4)
공개키 암호방식(비대칭키 암호방식)
송신자의 개인키로 암호화하는 경우 송신자 이외에는 암호화할 수 없으므로 송신인에 대한 인증 및 송신 부인봉쇄가 가능하나 공개키를 소유한 자는 누구나 메시지를 복호화 할 수 있으므로 기밀성은 제공되지 않음
2007-01
정보보호응용 28
SET의 보안기술 (5)
전자봉투(Digital Envelope)
개요 송신자가 송신내용을 암호화하기 위하여 사용한 비밀키 (Secret key, Symmetric Key)를 수신자만 볼 수 있도록 수신 자의 공개키(Public Key)로 암호화 시킨 것을 전자봉투라 함 특징 메시지 자체는 암호화 속도가 빠른 비밀키 암호화 방식으로 암호화하고 암호화에 사용된 비밀키를 공개키 암호화 방식을 이용하여 상대방에게 전달함으로써 공개키 암호화 방식의 장 점인 보안성을 유지하면서 공개키 암호화 방식의 단점인 처리 속도 지연문제를 해결함
2007-01
정보보호응용 29
SET의 보안기술 (6)
2007-01
정보보호응용 30
SET의 보안기술 (7)
전자서명(Digital Signature)
개요 전자서명은 서명자 인증, 메시지의 위/변조방지, 송신부인봉 쇄 등의 기능을 제공하는 암호화 기술로써 공개키 암호화 방 식에서의 개인키를 이용한 메시지 암호화는 서명 당사자밖에 할 수 없다는 점을 이용하여 구현함
2007-01
정보보호응용 31
SET의 보안기술 (8)
2007-01
정보보호응용 32
SET의 보안기술 (9)
Hash 함수 : 임의의 길이의 메시지에 적용하여 일정한 길이의 Code값(단, 다른 메시지마다 상이한 값)을 만들고, 결과 Code 값으로 원래의 메시지 를 확인할 수 없는 일방향 함수(또는 메시지 다이제스트 함수)를 말하며 전 참가기관이 동일한 함수를 사용함 메시지다이제스트(Message Digest) : 일방향 Hash함수를 적용한 결과값 160비트 전자서명 시 메시지다이제스트 사용이유 : 메시지 전체를 공개키 방식으 로 암호화하는 대신 메시지다이제스트를 암호화함으로써 처리시간을 단 축하고 전송된 메시지의 무결성을 확인하는 도구로 사용 RSA를 암호화 알고리즘으로 사용한다고 가정할 때 1kbyte 메시지 를 그대로 암호화 할 경우 소요시간은 약 8초, 메시지다이제스트를 암호화하는 경우는 약 0.16초가 소요 전자서명 처리절차 송신자는 송신할 메시지에 대해 Hash함수를 적용하여 160 비 트의 메시지 다이제스트를 생성 송신자는 생성된 메시지 다이제스트에 자신의 개인키를 이용하 여 공개키 암호화시킴으로써 전자서명을 실시한다 송신자는 송신 메시지와 전자서명을 수신자에게 전송한다
2007-01
정보보호응용 33
SET의 보안기술 (10)
전자서명 확인절차 수신자는 수신한 전자서명을 송신자의 공개키를 이용하여 복 호화함으로써 송신자가 생성한 메시지 다이제스트를 추출 수신자는 수신한 메시지에 송신자와 동일한 Hash함수를 적용 하여 새로운 메시지 다이제스트를 생성 수신자는 ④와 ⑤의 메시지다이제스트를 비교하여 동일한 경우 정당한 송신자의 전자서명으로 판단함
2007-01
정보보호응용 34
SET의 보안기술 (11)
사용 Key 종류
비밀키(Secret key, Symmetric key) : Data를 암호화 및 복호화할 때 사용하는 키 키교환용 공개키 및 개인키(Key-Exchange Public Key, Private Key) : Data를 암호화하기 위해 사용한 비밀키(Symmetric Key)를 교환할 때 동 키의 비밀유지를 위하여 사용하는 키 즉, 전자봉투(Digital Envelope) 생성시 사용하는 키 전자서명용 공개키 및 개인키(Signature Public Key, Private Key) : 전자서명의 생성 및 확인시 사용하는 키
2007-01
정보보호응용 35
SET에서의 프로토콜 (1)
기본 프로토콜
기밀성, 무결성, 인증, 부인봉쇄 등의 서비스제공을 위한 SET의 기 본 프로토콜로서 인증서 발급, 구매 등 보안이 필요한 전문 송수신 시 적용됨 본 기본 프로토콜을 수행하는데 필요한 수신인의 키 교환용 공개 키는 본 절차 수행 전 단계에서 수신 및 검증 완료됨
2007-01
정보보호응용 36
SET에서의 프로토콜 (2)
2007-01
정보보호응용 37
SET에서의 프로토콜 (3)
2007-01
정보보호응용 38
SET에서의 프로토콜 (4)
암호화 및 송신절차 송신인의 고유정보(Property)에 일방향 해쉬함수를 적용하여 메세 지 다이제스트 생성 송신인의 비밀서명키로 메시지 다이제스트를 암호화하여 디지탈 서명 생성 비밀키를 임의로 생성(Secret Key Random Generate) 고유정보, 디지털 서명, 송신자의 서명용 공개키가 들어있는 인증 서 사본을 ③에서 생성된 비밀키로 암호화 ④에서 사용한 비밀키를 수신인의 키교환 공개키로 암호화함으로 써 전자봉투(Digital Envelope) 생성 (송신인은 사전에 수신인의 키교환 공개키가 포함된 인증서를 가 지고 있음) 송신인은 ④의 결과와 ⑤의 결과를 수신인에게 전송함
2007-01
정보보호응용 39
SET에서의 프로토콜 (5)
수신 및 복호화 절차 수신인은 메세지를 수신후 우선적으로 전자봉투를 자신의 키교환 비밀키로 복호화하여 비밀키를 획득함 ⑦에서 획득한 비밀키를 이용 ④번의 암호문을 복호화함으로써 송 신된 고유정보, 디지탈 서명, 인증서의 평문정보를 알아냄 송신인의 인증서에 포함되어 있는 송신인의 서명용 공개키로 디지 털 서명을 복호화함으로써 송신인이 작성한 메시지 다이제스트 값 을 알아냄 ⑧에서 얻은 고유정보에 송신인이 사용한 동일한 일방향 해쉬함수 를 사용하여 새로운 메세지 다이제스트를 생성하고 ⑨에서 얻은 메시지 다이제스트와 비교하여 동일한 경우에만 정상적인 처리를 진행함 → 기밀성, 무결성, 상대방인증, 부인봉쇄의 보안서비스 가능
2007-01
정보보호응용 40
SET에서의 프로토콜 (6)
이중서명(Dual Signature) 프로토콜 필요성 SET에서는 고객의 결제정보가 판매자를 통하여 해당 지급정 보중계기관(이하 'PG')으로 전송됨에 따라 고객의 결제정보가 판매자에게 노출될 가능성과 판매자에 의한 결제정보의 위.변 조의 가능성이 있으므로, 판매자에게 결제정보를 노출시키지 않으면서도 판매자가 해당 고객의 정당성 및 구매내용의 정당 성을 확인할 수 있고 PG는 판매자가 전송한 결제요청이 실제 고객이 의뢰한 전문인지를 확인할 수 있도록 하는 이중서명 기술의 도입이 필요하게 되었음.
2007-01
정보보호응용 41
SET에서의 프로토콜 (7)
2007-01
정보보호응용 42
SET에서의 프로토콜 (8)
2007-01
정보보호응용 43
SET에서의 프로토콜 (9)
2007-01
정보보호응용 44
SET에서의 프로토콜 (10)
고객의 이중서명 생성 ㉠ 구매정보 OI에 대해 Hash함수를 적용하여 160 비트의 메시지 다이제스트 M1을 생성 ㉡ 결제정보 PI에 대해 Hash함수를 적용하여 160 비트의 메시지 다이제스트 M2를 생성 ㉢ 생성된 두개의 메시지다이제스트 M1,M2를 연접 (Concatenation)한 후 연접된 결과에 Hash함수를 적용하여 메시지 다이제스트 M을 생성 ㉣ M에 고객의 개인키로 전자서명 PG에게 전해질 전자봉투 생성 및 필요데이타의 판매자앞 전송 ㉠ 비밀키를 Random Generate하여 결제정보(PI)를 암호화 시킨 후 해당키를 PG의 공개키로 암호화하여 전자봉투 생성 ㉡ 구매정보, 암호화된 결제정보, M1M2, 고객의 전자서명, 전자 봉투를 판매자에게 전송
2007-01
정보보호응용 45
SET에서의 프로토콜 (11)
판매자는 구매정보와 이중서명 확인후 암호화된 결제정보를 PG 에게 전송 ㉠ 판매자는 수신된 구매정보(OI)에 고객과 동일한 Hash함수를 적용하여 메시지다이제스트 M1을 생성 ㉡ 판매자는 수신된 M1M2 중 M1을 새로 생성한 M1으로 대체시 킨후, 대체된 M1M2에 동일한 Hash함수를 적용하여 메시지 다이제스트 M을 구함 ㉢ 판매자는 수신된 이중서명을 고객의 공개키로 복호화하여 메 시지다이제스트 M을 추출 ㉣ 판매자는 ㉡과 ㉢의 메시지다이제스트를 비교하여 동일한 경 우 정당한 구매요청으로 간주하여 처리 ㉤ 판매자는 고객으로부터 전송받은 암호화된 결제정보(PI), 전 자봉투, 이중서명, M1M2를 자신의 승인요청전문 전송시 PG 로 전송
2007-01
정보보호응용 46
SET에서의 프로토콜(12)
PG의 전자봉투 및 결제정보 복호화 ㉠ PG는 자신의 개인키를 사용하여 전자봉투를 복호화 ㉡ 전자봉투에서 획득한 비밀키를 이용하여 결제정보, M1M2값, 고객의 서명값을 추출 PG의 고객 이중서명 확인 및 결제정보 확인 ㉠ PG는 복호화된 결제정보에 고객과 동일한 Hash함수를 적용 하여 메시지다이제스트 M2를 생성 ㉡ PG는 수신된 M1M2 중 M2을 새로 생성한 M2으로 대체시킨 후, 대체된 M1M2에 동일한 Hash함수를 적용하여 새로운 메 시지다이제스트 M을 구함 ㉢ PG는 수신된 고객의 이중서명을 고객의 공개키로 복호화하여 메시지다이제스트 M을 추출 ㉣ PG는 ㉡과 ㉢의 메시지다이제스트를 비교하여 동일한 경우 정당한 결제요청으로 간주하여 처리
2007-01
정보보호응용 47
SET에서의 프로토콜 (13)
인증서(Certificate) 이용 프로토콜
개 요 전자서명을 통한 인증서비스의 핵심인 거래상대방 공개키의 정 당성을 보장하기 위하여 전자상거래 전 참가기관은 전자상거래 이용전 자신의 공개키를 신뢰성 있는 인증기관의 인증서 발급 을 통해 공증토록 하고 전자상거래시 거래당사자는 인증기관의 인증서를 확인함으로써 상대방의 정당성을 확인할 수 있도록 함 → 인증기관의 설립 필요 고객 인증서 : 고객의 서명용 인증서만 발급 판매자 인증서 : 판매자의 서명용인증서와 키교환용 인증서를 쌍 으로 발급 지급정보중계기관 : 서명용인증서와 키교환용 인증서를 쌍으로 발 급
2007-01
정보보호응용 48
SET에서의 프로토콜 (14)
2007-01
정보보호응용 49
SET에서의 프로토콜 (15)
인증서 발급절차 고객/판매자/지급정보중계기관의 인증기관은 상위인증기관으로부 터 동 인증권한 및 인증서를 부여받음(이때 상위인증기관의 구성 은 가변적임) 피인증기관은 해당금융기관에 사전등록된 비밀번호등의 결제 또 는 판매자정보를 등록 양식에 입력하여 인증기관에 인증서 발급요 청 인증기관은 해당 금융기관으로 결제 또는 판매자정보를 송신하여 인증서발급 승인여부를 조회 ※ 고객과 금융기관간의 중요결제정보가 인증기관에 노출 해당 금융기관은 온라인 수신된 정보와 자체시스템 DB에 사전등 록된 정보와의 일치여부 판단 해당 금융기관은 비교 결과를 근거로 인증서발급 승인여부를 통보 인증기관은 해당 금융기관의 통보내용을 근거로 인증서발급 발급 또는 거부
2007-01
정보보호응용 50
SET에서의 프로토콜 (16)
인증서 확인절차 전자상거래 상대방의 인증서를 해당 인증기관의 공개키로 복호화 하여 거래상대방의 공개키를 획득한 후 동 공개키를 이용하여 거 래상대방의 전자서명을 확인한 결과가 일치할 경우 해당 거래당사 자를 인증기관이 인정한 정당거래자로 처리함. 이때 인증기관의 공개키 획득 및 확인절차는 다음과 같음 인증서의 정당성 여부를 확인하기 위해서는 인증서를 발급한 인증 기관의 공개키가 필요하고 이 경우 다시 해당인증기관의 공개키의 정당성을 보장하는 것이 문제가 됨. 따라서 SET 에서는 위의 그림 과 같이 전자상거래 참여자에게는 최상위 인증기관에 대한 공개키 (Root Key) 만을 공개하고 해당 인증기관의 정당성을 최상위 공개 키(Root Key)로서 관계된 인증기관(Trust Chain)의 인증서를 단계 적으로 풀어나감(Traverse)으로써 확인토록 조치함. 이때 최상위 공개키(Root Key)는 SET을 구현한 소프트웨어에 선 등록 조치가 필요함
2007-01
정보보호응용 51
SET에서의 프로토콜 (17)
2007-01
정보보호응용 52
SET에서의 프로토콜 (18)
SET에서의 인증서 발급체계
SET에서 제공하는 신뢰계층에서 Root는 전세계적으로 동일 Visa, Master등의 Brand계층에 대한 인증을 제공 Brand는 각 Brand의 지역별 관리국인 Geo-political의 인증을 제 공 Geo-political은 각 발급사와 매입사에 대한 인증을 제공 최상위 공개키를 생성한 기관은 필요시 모든 전자상거래 관련정보 의 복호화가 가능하게 됨
2007-01
정보보호응용 53
SET에서의 프로토콜 (19)
2007-01
정보보호응용 54
SET의 거래처리절차 (1)
2007-01
정보보호응용 55
SET의 거래처리절차 (2)
1.
고객은 인터넷상의 판매자에 접속하여 쇼핑한후 해당 판매자의 정당 성을 확인시켜주는 판매자 및 지급정보중계기관(이하 'PG')의 인증서 수신 2.
고객은 판매자와 PG 인증서를 확인하여 정당한 경우 상품주문 및 결 제정보와 자신의 인증서를 송부함으로써 구매요청을 함 3.
판매자는 고객인증서를 확인하여 정당한 경우 고객이 암호화한 결제 정보를 이용하여 해당 PG에게 승인요청하고 동시에 고객에게 구매응 답전문을 송신 4.
PG는 고객과 판매자의 인증서를 확인하여 정당한 경우 결제정보를 해당 금융기관이 이용가능한 내부 FORMAT으로 변환하여 승인요청 을 함 ※ 고객의 결제관련 정보가 PG에 노출됨
2007-01
정보보호응용 56
SET의 거래처리절차 (3)
5.
해당 금융기관은 고객의 신용한도를 고려하여 승인여부를 전송 6.
PG는 해당전문을 SET FORMAT으로 변환하여 판매자에게 전송 7.
판매자는 PG의 응답전문에 의거하여 해당고객에 영수증 및 물품을 인도 8.
PG는 판매자와 고객은행간의 정상처리분에 대한 결제요청 처리를 실 시
2007-01
정보보호응용 57
거래 및 결제처리 과정 (1)
구 매(Purchase Request)
2007-01
정보보호응용 58
거래 및 결제처리 과정 (2)
1.
고객 요청 개시 a.
고객 쇼핑 b.
고객 소프트웨어는 판매자에게 첫 요청전문(Initiate Request) 전 송 2.
판매자 인증서 전송 a.
판매자 소프트웨어는 첫 요청전문 수신 b.
판매자 소프트웨어는 응답전문(Initiate Response)을 생성하여 전 자서명 수행(응답전문의 메세지다이제스트을 생성하여 판매자의 서명용 개인키로 암호화함) c.
판매자 소프트웨어는 고객에게 판매자와 지급정보 중계기관(이하 PG)의 인증서, 구매 트랜젝션 고유로 생성되는 트랜젝션 ID를 응 답전문과 함께 전송
2007-01
정보보호응용 59
거래 및 결제처리 과정 (3)
3.
고객 응답전문 수신 및 구매요청전문(Purchase Request) 전송 a.
고객 소프트웨어는 첫 응답전문을 수신하고 루트키에 대한 신뢰계층 (Trust Chain)에 의해 판매자와 PG인증서 검증 b.
고객 소프트웨어는 판매자의 서명 검증(판매자의 서명용 공개키로 복호 화하고 응답전문에 대해 새로 생성된 해쉬와 그 결과를 비교함) c.
d.
e.
고객 소프트웨어는 쇼핑시 획득한 정보를 사용하여 주문정보(OI) 생성 고객은 결제지시전문(PI) 작성 고객 소프트웨어는 이중서명 생성(주문정보(OI)와 결제지시전문(PI) 각 각의 메시지다이제스트 M1, M2를 연결(M1M2)한 후 다시 새로운 메세지 다이제스트(M)를 생성하고, 이 이중해쉬를 고객의 서명용 개인키로 암호 화함) f.
고객 소프트웨어는 임의로 생성된 비밀키(#1)로 결제지시전문(PI)을 암 호화(이중서명, M1M2까지 포함하여)하고 이 키는 고객의 금융정보와 함 께 지급정보 중계기관의 키교환용 공개키로 암호화하여 전자봉투 생성 g.
고객 소프트웨어는 이중서명, M1M2, 주문정보(OI), 암호화된 결제지시 전문(PI), 전자봉투, 고객 인증서를 판매자에게 전송
2007-01
정보보호응용 60
거래 및 결제처리 과정 (4) 4.
판매자 요청 메세지 처리
a.
판매자 소프트웨어는 루트키 신뢰계층에 의해 고객의 인증서검증 b.
판매자 소프트웨어는 주문정보에 대한 고객의 이중서명 검증 c.
판매자의 승인요청전문 전송(Request Authorization) - 승인을 위해 PG로 결제지시전문(PI)을 전송 d.
판매자 소프트웨어는 구매응답전문(Purchase Response)을 생성 하고 전자서명함(구매응답전문의 메세지다이제스트를 생성하고 판매자의 서명용 개인키로 암호화) e.
판매자 소프트웨어는 고객에게 구매응답전문, 전자서명, 판매자 의 서명 인증서 전송(고객에게 응답을 전송하기 전에 결제승인을 받을 필요는 없음) f.
거래가 승인되면 판매자는 상품을 전달함으로써 고객의 주문 이 행
2007-01
정보보호응용 61
거래 및 결제처리 과정 (5) 5.
고객의 구매응답전문 수신
a.
고객 소프트웨어는 루트키의 신뢰계층에 의해 판매자의 서명 인 증서 검증 b.
고객 소프트웨어는 판매자의 전자서명 검증(판매자의 서명용 공 개키로 복호화하여 새로 생성된 구매응답전문의 해쉬와 비교함) c.
고객 소프트웨어는 응답내용을 디스플레이하고 구매응답전문 저 장 ※ 고객은 구매조회전문(Order Inquiry message)을 전송함으로 써 구매승인 여부와 같은 구매관련 내용의 조회가 가능
2007-01
정보보호응용 62
거래 및 결제처리 과정 (6)
결제 승인(Payment Authorization )
2007-01
정보보호응용 63
거래 및 결제처리 과정 (7)
판매자 승인 요청(Authorization Request)
판매자 소프트웨어는 트랜젝션 ID, 기타 트랜젝션 관련정보를 포 함하는 판매대금결제요청전문(Authorization Request) 생성 판매자 소프트웨어는 판매대금결제요청전문에 대해 전자서명 수 행(판매대금결제요청에 대한 메세지다이제스트를 생성하고 판매 자의 서명용 개인키로 암호화함) 판매자 소프트웨어는 임의로 생성된 비밀키(#2)로 전자서명이 포 함된 판매대금결제요청전문을 암호화하고 이 키는 PG의 키교환 용 공개키로 암호화하여 전자봉투 생성 판매자 소프트웨어는 암호화된 판매대금결제요청전문과 ㉢에서 생성된 전자봉투, 고객의 구매요청전문에서 획득한 암호화된 결 제지시전문(PI)과 전자봉투, 고객 서명 인증서, 판매자 서명 인증 서, 판매자 키교환 인증서를 PG에게 전송
2007-01
정보보호응용 64
거래 및 결제처리 과정 (8)
지급정보 중계기관(PG) 승인 요청 처리
PG는 루트키의 신뢰계층(Trust Chain)에 의해 판매자의 인증서 검증 PG는 자신의 키교환용 개인키로 ㉢에서 생성된 전자봉투를 복호 화하여 비밀키(#2)를 획득하고 이 비밀키(#2)를 사용하여 판매대 금결제요청전문 복호화 PG는 판매자의 전자서명 검증(판매자의 서명용 공개키로 전자서 명을 복호화하고 판매대금결제요청전문에 대해 새로 생성된 해쉬 를 비교함) PG는 루트키의 신뢰계층에 의해 고객의 인증서 검증 PG는 자신의 키교환용 개인키로 판매자를 통해 고객으로부터 전 송되어온 전자봉투를 복호화하여 비밀키(#1)와 고객의 금융정보 를 획득하고 이 비밀키(#1)를 사용하여 결제지시전문(PI) 복호화
2007-01
정보보호응용 65
거래 및 결제처리 과정 (9)
PG는 결제지시전문(PI)에 대한 고객의 이중서명 검증(새로 생성된 결제지시전문의 메시지다이제스트 M2를 수신된 M1M2의 M2와 대 체하고 M1M2에 대한 새로운 메시지다이제스 M을 생성하여, 고객 의 서명용 공개키로 이중서명을 복호화한 M과 비교함) PG는 판매자의 판매대금결제요청전문과 고객의 결제지시전문(PI) 사이의 일치성 확인 PG는 금융망을 통해 고객의 금융기관과 판매대금결제지시전문 및 판매대금결제승락/거부보고전문을 송 · 수신 PG는 판매대금승락/거부통보전문(Authorization Response)을 생 성하여 전자서명 수행(판매대금승락/거부통보전문에 대한 메세지 다이제스트를 생성하고 중계기관의 서명용 비밀키로 암호화함) PG는 임의로 생성된 비밀키(#3)로 판매대금승락/거부통보전문을 암호화하고 이 키는 판매자의 키교환용 공개키로 암호화하여 전자 봉투 생성
2007-01
정보보호응용 66
거래 및 결제처리 과정 (10)
PG는 임의로 생성된 비밀키(#3)로 판매대금승락/거부통보전문을 암호화하고 이 키는 판매자의 키교환용 공개키로 암호화하여 전 자봉투 생성 PG는 결제처리토큰(Capture Token) 생성(매입사에 따라 생성여 부 결정) PG는 임의로 생성된 비밀키(#4)로 결제처리토큰(Capture Token) 을 암호화하고 이 키와 고객의 금융정보를 PG의 키교환용 공개키 로 암호화하여 전자봉투 생성 PG는 ㉩, ㉫의 결과, PG의 서명 인증서를 판매자에게 전송 ※ 결제처리토큰(Capture Token)은 매입사의 방침에 따라 생성 및 사용여부를 결정하며, 이후 언급되는 결제처리토큰관련 절차 는 그 생성을 전제로 한 것임
2007-01
정보보호응용 67
거래 및 결제처리 과정 (11)
판매자 응답 처리
판매자 소프트웨어는 루트키의 신뢰계층에 의해 PG인증서 검증 판매자 소프트웨어는 판매자의 키교환용 개인키로 ②-㉩에서 생 성된 전자봉투를 복호화하여 비밀키(#3)를 획득하고 동 키를 사 용하여 PG의 판매대금결제승락/거부통보전문 복호화 판매자 소프트웨어는 PG의 전자서명 검증(PG의 서명용 공개키로 복호화하고 판매대금결제승락/거부통보전문에 대해 새로 생성된 해쉬를 비교함) 판매자는 다.결제처리과정(Payment Capture)을 위해 암호화된 결제처리토큰(Capture Token)과 ②-㉫에서 생성된 전자봉투 저 장 승인된 거래인 경우 판매자는 상품을 전달함으로써 고객의 주문 이행
2007-01
정보보호응용 68
거래 및 결제처리 과정 (12)
결제 처리(Payment Capture)
2007-01
정보보호응용 69
거래 및 결제처리 과정 (13)
판매자 결제처리요청
판매자 소프트웨어는 결제처리요청전문(Capture Request) 생성 판매자 소프트웨어는 결제처리요청전문에 전자서명(결제처리요 청전문의 메세지다이제스트을 생성하여 판매자의 서명용 비밀키 로 암호화함) 판매자 소프트웨어는 임의로 생성된 비밀키(#5)로 결제처리요청 전문을 암호화하고 이 키는 PG의 키교환용 공개키로 암호화 판매자 소프트웨어는 암호화된 결제처리요청전문, 전자서명, 판 매자 서명 인증서, 결제승인과정(Payment Authorization)에서 전 송받은 암호화된 결제처리토큰(Capture Token) 및 전자봉투도 함께 전송
2007-01
정보보호응용 70
거래 및 결제처리 과정 (14)
지급정보 중계기관(PG) 결제처리요청 처리
PG는 루트키의 신뢰계층(Trust Chain)에 의해 판매자의 인증서 검증 PG는 자신의 키교환용 개인키로 전자봉투를 복호화하여 비밀키 (#5)를 획득하고 이 비밀키(#5)를 사용하여 결제처리요청전문 복 호화 PG는 판매자 전자서명 검증(판매자의 서명용 공개키로 복호화하 고 새로 생성된 결제처리요청전문의 해쉬와 비교함) PG는 결제승인과정(Payment Authorization)에서 생성된 전자봉 투를 자신의 키교환용 개인키로 복호화하여 비밀키(#4)를 획득하 고 동 비밀키(#4)를 사용하여 결제처리토큰(Capture Token) 복 호화
2007-01
정보보호응용 71
거래 및 결제처리 과정 (15)
PG는 판매자의 결제처리요청전문과 결제처리토큰사이의 일치성 확인 PG는 금융망을 통해 고객의 금융기관에 결제처리요청전문 전송 PG는 결제처리응답전문(Capture Response)을 생성하여 전자서 명(결제처리 응답전문의 메세지다이제스트를 생성하여 PG 서명용 비밀키로 암호화함) PG는 임의로 생성된 비밀키(#6)로 결제처리응답전문을 암호화하 고 이 키는 판매자의 키교환용 공개키로 암호화하여 전자봉투 생 성 PG는 암호화된 결제처리응답전문, 전자서명, 전자봉투를 판매자 에게 전송
2007-01
정보보호응용 72
거래 및 결제처리 과정 (16)
판매자 응답전문 수신
판매자 소프트웨어는 루트키의 신뢰계층에 의해 PG의 인증서 검 증 판매자 소프트웨어는 판매자의 키교환용 개인키로 전자봉투를 복 호화하여 비밀키(#6)를 획득하고 이 비밀키(#6)를 사용하여 결제 처리응답전문 복호화 판매자 소프트웨어는 PG의 전자서명 검증(PG의 서명용 공개키로 복호화하고 새로 생성된 결제처리응답전문의 해쉬와 비교함) 판매자 소프트웨어는 매입사와 결제에 관련된 분쟁발생시 사용하 기 위하여 결제처리응답전문을 저장 ※ 다. 결제처리(Payment Capture)과정은 주로 Batch로 처리될 예정이며, 결제처리 요청전문의 전송은 Header, Detail, Trailer의 레코드로 이루어진 파일형식을 사용하여 전송함
2007-01
정보보호응용 73