10. 전자상거래 보안 e-commerce security

Presentation on theme: "10. 전자상거래 보안 e-commerce security"— Presentation transcript:

1 10. 전자상거래 보안 e-commerce security

2 개요 (1) 전자지불 프로토콜의 필요성 전자지불 프로토콜의 종류
전자상거래(e― commerce, m― commerce)에서의 물품구매에 따른 결제 수단이 필요 전자지불 프로토콜의 종류 전자화폐 안정성, 이중사용방지,익명성,프라이버시보호,전자현금의 분할 사용등의 사항이 최대한 보장 카드결제 프로토콜 소액지불 프로토콜 거액거래에 요구되는 정도의 안전성은 필요하지 않음 소액에 적합한 안전성보장과 빠른 속도의 효율성 필요 계산량 감소가 필요하고, 통신양 감소 필요 전자수표 2

3 개요 (2) 전자상거래 지불 시스템 신용카드 기반 전자화폐 기반 지불프로토콜 소액지불 프로토콜 전자화폐 프로토콜 S-HTTP
SSL TLS 기타 SET Non-SET - CyberCash - FirstVirtual - 기타 NetBill Ecash Mondex 웹 기반 웹 연동, 전자지갑 웹 연동, 전자지갑, 스마트카드 오프라인방식, 스마트카드, 오프라인 단말기 보안프로토콜 3

4 전자화폐 (1) 개요 Blind signature 전자상거래 수행에 필수적으로 요구되는 기술
공개된 통신망을 통해 다자간이 자신의 비밀은 노출하지 아니하고 상대방에게 비밀의 소유 사실을 납득시키는 방법이 필요 Blind signature, zero-knowledge, bit commitment 등 Blind signature 1983년 David Chaum에 의해 제안 RSA Signature를 기반으로 서명하고자 하는 문서의 내용을 비밀로 유지하고자 할때 사용 전자화폐에서 은행에 의한 개인의 정보와 화폐사용처를 추적하는 것을 방지 4

5 전자화폐 (2) user bank α∈R {1,n} t = mαe mod n S’ = td mod n
= (mαe )d mod n t S’ td = (mαe )d mod n td/α = md α/ α =md mod n S = S’ /α mod n  Blind signature 프로토콜 m : message α : blind factor e : bank’s public key d : bank’s private key 5

6 전자화폐 (3) 전자화폐의 기본 구성 요소 은행 고객 상점 ③예치단계 ①인출단계 ②지불단계 6

7 전자화폐 (4) 전자화폐 기본 프로토콜 인출 프로토콜 (withdrawal protocol)
사용자와 은행 사이에서 수행되는 프로토콜 은행이 사용자에게 전자화폐를 발급해 주는 절차를 명세한 것 전자화폐 시스템 설계할 때 가장 중요한 부분 지불 프로토콜(payment protocol) 사용자와 상점 사이에서 수행되는 프로토콜 사용자가 구매대금으로 자신의 전자화폐를 상점에 지불하는 과정을 명세 예치 프로토콜(deposit protocol) 상점과 은행 사이에서 수행되는 프로토콜 상점이 사용자로부터 받은 전자화폐를 은행이 결제 7

8 전자화폐 (5) On-line System Off-line System 결제단계가 이루어지기 전에 은행의 데이타베이스를 검색
지불과 결제가 일괄적으로 처리됨 사용되는 현금의 이중사용여부를 확인 매 결제단계마다 상점이 은행과 연결 Off-line System Smart card 등을 이용하여 지불만 수행 지불 후 상점에 의한 결제 프로토콜은 따로 수행 지불과 결제가 동시에 수행되지 않으므로 이중사용방지 기법이 필요 8

9 전자화폐 (6) 전자화폐 위협요소 위조(Forgery) : 은행을 제외한 참가자가 인출 프로토콜에 참가한 후에 인출한 전자현금의 금액을 액면가에 초과하는 전자현금으로 바꾸어 그것이 은행에 의해 유효하게 받아들여지게 하는 공격 이중사용(Double spending) : 사용자가 발급받은 전자현금을 한번 이상 사용하는 행위 초과사용(Over spending) : 사용자가 발급받은 액면가 이상의 금액을 사용하는 행위 위장(Impersonation) : 공격자가 마치 사용자인 것처럼 사용자의 계좌에 접근하여 돈을 가로채는 공격 돈세탁(Money laundering) : 불법적인 돈의 출처를 감추기 위하여 행해지는 이체 9

10 전자화폐 (7) 불법구매 (Illegal purchases) : 마약의 구매와 같은 불법적인 물품구매
약탈(Blackmail) : 공격자가 사용자에게 사용자의 계좌 에서 돈을 인출할 것을 강요하고 공격자가 추적당하지 않고 돈을 입금시키거나 사용할 수 있는 방법으로 공격자에게 돈을 전송하도록 하는 공격 은행강탈(Bank robbery) : 공격자들의 집단이 은행에게 추후 사용할 수 있는 돈을 얻도록 프로토콜에 참여하기를 강요하는 공격 10

11 전자화폐 (8) 기본적인 요구사항 이중사용방지(double spending prevention) : 오프라인 전자화폐는 사용자가 같은 코인을 두 번 사용할 수 없어야 함 익명성(anonymity) :실물화폐와 마찬가지로 은행이 신뢰기관의 협조없이 전자화폐와 정직한 사용자의 신원을 연결시키는 것을 불가능하게 해야 함 추적불가능성(untraceability):전자현금과 사용자 사이의 관계는 권한이 부여된 익명성 취소의 경우를 제외하고는 은행이 추적하지 못하도록 해야 함 완전정보화 :모든 정보는 디지털화 되어있어 비트의 기본요소로 구성 위조 불가능성(unforgeability) :은행과 같이 권한이 부여된 참가자만이 전자현금을 발행할 수 있어야 함 11

12 전자화폐 (9) 추가적인 요구사항 분할성(divisiability): 먼저 정확한 금액의 지불을 위하여 전자현금의 액면금액에 대해서 더 작은 단위로 나누어질 수 있어야 함 양도성(transferability): 한번 인출된 전자현금이 다른 사용자에게 양도가 가능해야 함 연결불가능성(unlinkability): 동일 사용자가 사용한 서로 다른 전자현금과의 연결 불가 공정성(fairness): 사용자는 신뢰기관과 은행에 대해서 각각 익명성이 보장되어야 하는데, 이 두 기관의 합법적인 협조에 의해서만 익명성이 조건적으로 철회될 수 있어야 함 사용자 추적(user-tracing): 은행과 신뢰기관은 사용된 전자현금과 사용자를 연결 현금추적(coin-tracing): 사용될 전자현금과 예치된 전자현금과 관련된 정보가 일치하는지를 계산가능 해야 함 12

13 전자화폐 (10) 초과사용 추적(overspent-tracing)
오프라인 전자화폐에서 이중 사용 이외에도 초과사용이 가능할 수도 있기 때문에 은행은 전자현금을 초과 사용한 사용자의 신분을 알 필요가 있음 효율성(efficiency) 전자화폐가 실용적으로 사용되기 위해서는 저장용량, 통신량, 계산량에 있어서 효율적이어야 함 13

14 NetBill (1) CMU에서 개발한 지불시스템으로 주로 저가의 정보상품 및 소프트웨어 구매와 판매에 적합하게 설계됨.
은행 NetBill Server 구매자가 어떤 정보상품을 구입하게 되면 NetBill 서버의 구매자 계좌에서 해당 액수만큼 출금이 되고 동시에 판매자 계좌에 그 액수가 입금된다. 지불 방식은 전자수표에 기반 Network 구매인 판매자 14

15 NetBill (2) 구매자는 구매요청서를 판매자에게 보낸다. 판매자는 견적서를 구매자에게 보낸다.
구매자가 판매자에게 구매 요청을 한다. 판매자는 암호화된 정보와 무결성을 보장하는 해쉬 값을 구매자에게 보낸다. 구매자는 자신이 계산한 해쉬 값과 판매자가 보낸 해쉬 값이 일치하는 지를 확인함으로써 자신이 요청한 정보가 정확히 수신되었다는 것을 확인한다. 구매자는 자신이 디지털 서명한 전자 지불요청서를 판매자에게 보낸다. 판매자는 이것을 NetBill 서버에 보내어 구매자의 계좌가 유효한지 확인한다. NetBill 서버로부터의 승인이 떨어지면 판매자는 자신이 암호화한 정보를 복호화 할 수 있는 키를 구매자에게 전달한다. 15

16 NetBill (3) 16

17 NetBill : 가격요청 1 2 구매자가 특정 정보상품의 구입을 결정하였으면 티켓과 구매요청서를 판매자에게 보낸다.
판매자는 으로부터 대칭키 을 구하여 구매 요청서를 복호화 한다. 판매자는 price와 TID를 암호화하여 구매자에게 보낸다. Product_request_data: 구매자가 요청하는 상품 TID: 거래 식별번호 17

18 NetBill : 상품인도 3 4 3. 구매자는 암호화된 TID를 보내 구매의사를 표시한다.
(이 시점에서 거래를 취소할 수 없음) 4. 판매자는 임의로 생성한 대칭키 를 이용하여 정보상품 Goods를 암호화하고 또한 암호화된 정보상품을 공개된 해쉬함수 SHA를 통해 해쉬 값을 구하여 이것 역시 상호간에 공유된 대칭키 으로 암호화하여 구매자에게 보낸다. EPOID(electronic payment order ID): NetBill 데이터베이스에서 거래를 식별하기 위하여 사용되는 값 18

19 NetBill : 지불프로토콜 19

20 NetBill : 지불프로토콜-1 5 5. 구매자는 전자 지불요청서 EPO를 작성하여 여기에 자신의 디지털 서명을 첨가한 후에 티켓과 함께 판매자에게 보낸다. EPO는 두 부분으로 구성 됨 판매자와 NetBill 서버가 모두 읽을 수 있는 내용 --- 구매자 ID, 상품가격, 판매자 ID등 NetBill 서버만 읽을 수 있는 내용 --- 구매자와 서버간에 공유된 대칭키 으로 암호화된 지불관련 내용들, 즉 구매자의 신원을 증명하는 티켓, 구매자 계좌번호 등 20

21 SET의 개요 (1) SET의 개념 SET(Secure Electronic Transaction)은 안전한 지급결제수단을 제공하기 위하여 비자와 마스터카드사가 공동으로 개발한 신용/직불카드결제용 전문 및 보안 프로토콜 기술지원사 GTE, IBM, Microsoft, Netscape, SAIC, Terisa, Verisign ' : 초안 발표 ( ' 일 버전 1.0 발표 ) 상호운용성 보장 : SET을 적용한 각 사의 제품간 상호운용성 보장을 위하여 SET 적용제품은 SAIC(Science Applications International Corporation)에서 테스트 및 인증을 거치도록 하고있음 21

22 SET의 개요 (2) SET에서의 보안 서비스 기밀성(Confidentiality) : 통신회선상의 비밀정보 암호화 기능
무결성(Integrity) : 통신회선상의 정보변질여부 확인 기능 인증(Authentication) : 통신 상대방의 정당성 확인 기능 부인봉쇄(Non-Repudiation) : 통신 상대방간 송·수신 사실부인 방지기능 22

23 SET의 구성요소 (1) 23

24 SET의 구성요소 (2) 고객(Cardholder) : 인터넷쇼핑몰에서 물품 또는 서비스를 구매하는 자
판매자(Merchant) : 인터넷상에서 상품이나 서비스를 제공하는자 발급사(Issuer) : 고객의 카드발급 금융기관 혹은 결제카드 소지인의 계좌가 개설되어 있는 금융기관 매입사(Acquirer) : 판매자의 가맹점 승인 금융기관 혹은 판매자의 계좌가 개설되어 있는 금융기관 지급정보 중계기관(Payment Gateway) : 판매자가 요청한 고객의 지급 정보로 해당 금융기관에 승인 및 결제를 요청하는 기관 인증기관(Certification Authority) : 고객 및 판매자 등 각 참여기관이 인터넷 상에서 서로 신뢰하면서 거래할 수 있도록 각 참여기관에게 전자적인 인증서를 발급하는 기관 24

25 SET의 보안기술 (1) 기본 암호기술 SET의 보안 프로토콜 비밀키 암호방식(대칭키 암호방식)
공개키 암호방식(비대칭키 암호방식) 전자봉투(Digital Envelope) 전자서명(Digital Signature) SET의 보안 프로토콜 사용 Key 종류 기본 프로토콜 이중서명(Dual Signature) 프로토콜 인증서(Certificate) 이용 프로토콜 25

26 SET의 보안기술 (2) 비밀키 암호방식(대칭키 암호방식) 비교적 구현이 용이하고 실행속도가 빠른편
키 분배 및 관리가 어렵고 거래쌍방이 동일한 키를 사용하는 관계로 송수신 부인시 해결책이 없음 26

27 SET의 보안기술 (3) 공개키 암호방식(비대칭키 암호방식) 수신자의 공개키로 암호화하는 경우
수신자 이외에는 암호문을 해독할 수 없으므로 전송 메시지의 기밀성이 보장됨 27

28 SET의 보안기술 (4) 공개키 암호방식(비대칭키 암호방식) 송신자의 개인키로 암호화하는 경우
송신자 이외에는 암호화할 수 없으므로 송신인에 대한 인증 및 송신 부인봉쇄가 가능하나 공개키를 소유한 자는 누구나 메시지를 복호화 할 수 있으므로 기밀성은 제공되지 않음 28

29 SET의 보안기술 (5) 전자봉투(Digital Envelope) 개요
송신자가 송신내용을 암호화하기 위하여 사용한 비밀키(Secret key, Symmetric Key)를 수신자만 볼 수 있도록 수신자의 공개키(Public Key)로 암호화 시킨 것을 전자봉투라 함 특징 메시지 자체는 암호화 속도가 빠른 비밀키 암호화 방식으로 암호화하고 암호화에 사용된 비밀키를 공개키 암호화 방식을 이용하여 상대방에게 전달함으로써 공개키 암호화 방식의 장점인 보안성을 유지하면서 공개키 암호화 방식의 단점인 처리속도 지연문제를 해결함 29

30 SET의 보안기술 (6) 30

31 SET의 보안기술 (7) 전자서명(Digital Signature) 개요
전자서명은 서명자 인증, 메시지의 위/변조방지, 송신부인봉쇄 등의 기능을 제공하는 암호화 기술로써 공개키 암호화 방식에서의 개인키를 이용한 메시지 암호화는 서명 당사자밖에 할 수 없다는 점을 이용하여 구현함 31

32 SET의 보안기술 (8) 32

33 SET의 보안기술 (9) Hash 함수 : 임의의 길이의 메시지에 적용하여 일정한 길이의 Code값(단, 다른 메시지마다 상이한 값)을 만들고, 결과 Code 값으로 원래의 메시지를 확인할 수 없는 일방향 함수(또는 메시지 다이제스트 함수)를 말하며 전 참가기관이 동일한 함수를 사용함 메시지다이제스트(Message Digest) : 일방향 Hash함수를 적용한 결과값 160비트 전자서명 시 메시지다이제스트 사용이유 : 메시지 전체를 공개키 방식으로 암호화하는 대신 메시지다이제스트를 암호화함으로써 처리시간을 단축하고 전송된 메시지의 무결성을 확인하는 도구로 사용 RSA를 암호화 알고리즘으로 사용한다고 가정할 때 1kbyte 메시지를 그대로 암호화 할 경우 소요시간은 약 8초, 메시지다이제스트를 암호화하는 경우는 약 0.16초가 소요 전자서명 처리절차 송신자는 송신할 메시지에 대해 Hash함수를 적용하여 160 비트의 메시지 다이제스트를 생성 송신자는 생성된 메시지 다이제스트에 자신의 개인키를 이용하여 공개키 암호화시킴으로써 전자서명을 실시한다 송신자는 송신 메시지와 전자서명을 수신자에게 전송한다 33

34 SET의 보안기술 (10) 전자서명 확인절차 수신자는 수신한 전자서명을 송신자의 공개키를 이용하여 복호화함으로써 송신자가 생성한 메시지 다이제스트를 추출 수신자는 수신한 메시지에 송신자와 동일한 Hash함수를 적용하여 새로운 메시지 다이제스트를 생성 수신자는 ④와 ⑤의 메시지다이제스트를 비교하여 동일한 경우 정당한 송신자의 전자서명으로 판단함 34

35 SET의 보안기술 (11) 사용 Key 종류 비밀키(Secret key, Symmetric key) : Data를 암호화 및 복호화할 때 사용하는 키 키교환용 공개키 및 개인키(Key-Exchange Public Key, Private Key) : Data를 암호화하기 위해 사용한 비밀키(Symmetric Key)를 교환할 때 동 키의 비밀유지를 위하여 사용하는 키 즉, 전자봉투(Digital Envelope) 생성시 사용하는 키 전자서명용 공개키 및 개인키(Signature Public Key, Private Key) : 전자서명의 생성 및 확인시 사용하는 키 35

36 SET에서의 프로토콜 (1) 기본 프로토콜 기밀성, 무결성, 인증, 부인봉쇄 등의 서비스제공을 위한 SET의 기본 프로토콜로서 인증서 발급, 구매 등 보안이 필요한 전문 송수신시 적용됨 본 기본 프로토콜을 수행하는데 필요한 수신인의 키 교환용 공개키는 본 절차 수행 전 단계에서 수신 및 검증 완료됨 36

37 SET에서의 프로토콜 (2) 37

38 SET에서의 프로토콜 (3) 38

39 SET에서의 프로토콜 (4) 암호화 및 송신절차
송신인의 고유정보(Property)에 일방향 해쉬함수를 적용하여 메세지 다이제스트 생성 송신인의 비밀서명키로 메시지 다이제스트를 암호화하여 디지탈서명 생성 비밀키를 임의로 생성(Secret Key Random Generate) 고유정보, 디지털 서명, 송신자의 서명용 공개키가 들어있는 인증서 사본을 ③에서 생성된 비밀키로 암호화 ④에서 사용한 비밀키를 수신인의 키교환 공개키로 암호화함으로써 전자봉투(Digital Envelope) 생성 (송신인은 사전에 수신인의 키교환 공개키가 포함된 인증서를 가지고 있음) 송신인은 ④의 결과와 ⑤의 결과를 수신인에게 전송함 39

40 SET에서의 프로토콜 (5) 수신 및 복호화 절차
수신인은 메세지를 수신후 우선적으로 전자봉투를 자신의 키교환비밀키로 복호화하여 비밀키를 획득함 ⑦에서 획득한 비밀키를 이용 ④번의 암호문을 복호화함으로써 송신된 고유정보, 디지탈 서명, 인증서의 평문정보를 알아냄 송신인의 인증서에 포함되어 있는 송신인의 서명용 공개키로 디지털 서명을 복호화함으로써 송신인이 작성한 메시지 다이제스트 값을 알아냄 ⑧에서 얻은 고유정보에 송신인이 사용한 동일한 일방향 해쉬함수를 사용하여 새로운 메세지 다이제스트를 생성하고 ⑨에서 얻은 메시지 다이제스트와 비교하여 동일한 경우에만 정상적인 처리를 진행함 → 기밀성, 무결성, 상대방인증, 부인봉쇄의 보안서비스 가능 40

41 SET에서의 프로토콜 (6) 이중서명(Dual Signature) 프로토콜 필요성
SET에서는 고객의 결제정보가 판매자를 통하여 해당 지급정보중계기관(이하 'PG')으로 전송됨에 따라 고객의 결제정보가 판매자에게 노출될 가능성과 판매자에 의한 결제정보의 위.변조의 가능성이 있으므로, 판매자에게 결제정보를 노출시키지 않으면서도 판매자가 해당 고객의 정당성 및 구매내용의 정당성을 확인할 수 있고 PG는 판매자가 전송한 결제요청이 실제 고객이 의뢰한 전문인지를 확인할 수 있도록 하는 이중서명 기술의 도입이 필요하게 되었음. 41

42 SET에서의 프로토콜 (7) 42

43 SET에서의 프로토콜 (8) 43

44 SET에서의 프로토콜 (9) 44

45 SET에서의 프로토콜 (10) 고객의 이중서명 생성
㉠ 구매정보 OI에 대해 Hash함수를 적용하여 160 비트의 메시지 다이제스트 M1을 생성 ㉡ 결제정보 PI에 대해 Hash함수를 적용하여 160 비트의 메시지 다이제스트 M2를 생성 ㉢ 생성된 두개의 메시지다이제스트 M1,M2를 연접(Concatenation)한 후 연접된 결과에 Hash함수를 적용하여 메시지 다이제스트 M을 생성 ㉣ M에 고객의 개인키로 전자서명 PG에게 전해질 전자봉투 생성 및 필요데이타의 판매자앞 전송 ㉠ 비밀키를 Random Generate하여 결제정보(PI)를 암호화 시킨후 해당키를 PG의 공개키로 암호화하여 전자봉투 생성 ㉡ 구매정보, 암호화된 결제정보, M1M2, 고객의 전자서명, 전자봉투를 판매자에게 전송 45

46 SET에서의 프로토콜 (11) 판매자는 구매정보와 이중서명 확인후 암호화된 결제정보를 PG에게 전송
㉠ 판매자는 수신된 구매정보(OI)에 고객과 동일한 Hash함수를 적용하여 메시지다이제스트 M1을 생성 ㉡ 판매자는 수신된 M1M2 중 M1을 새로 생성한 M1으로 대체시킨후, 대체된 M1M2에 동일한 Hash함수를 적용하여 메시지다이제스트 M을 구함 ㉢ 판매자는 수신된 이중서명을 고객의 공개키로 복호화하여 메시지다이제스트 M을 추출 ㉣ 판매자는 ㉡과 ㉢의 메시지다이제스트를 비교하여 동일한 경우 정당한 구매요청으로 간주하여 처리 ㉤ 판매자는 고객으로부터 전송받은 암호화된 결제정보(PI), 전자봉투, 이중서명, M1M2를 자신의 승인요청전문 전송시 PG로 전송 46

47 SET에서의 프로토콜(12) PG의 전자봉투 및 결제정보 복호화 ㉠ PG는 자신의 개인키를 사용하여 전자봉투를 복호화
㉡ 전자봉투에서 획득한 비밀키를 이용하여 결제정보, M1M2값, 고객의 서명값을 추출 PG의 고객 이중서명 확인 및 결제정보 확인 ㉠ PG는 복호화된 결제정보에 고객과 동일한 Hash함수를 적용하여 메시지다이제스트 M2를 생성 ㉡ PG는 수신된 M1M2 중 M2을 새로 생성한 M2으로 대체시킨후, 대체된 M1M2에 동일한 Hash함수를 적용하여 새로운 메시지다이제스트 M을 구함 ㉢ PG는 수신된 고객의 이중서명을 고객의 공개키로 복호화하여 메시지다이제스트 M을 추출 ㉣ PG는 ㉡과 ㉢의 메시지다이제스트를 비교하여 동일한 경우 정당한 결제요청으로 간주하여 처리 47

48 SET에서의 프로토콜 (13) 인증서(Certificate) 이용 프로토콜 개 요
전자서명을 통한 인증서비스의 핵심인 거래상대방 공개키의 정당성을 보장하기 위하여 전자상거래 전 참가기관은 전자상거래 이용전 자신의 공개키를 신뢰성 있는 인증기관의 인증서 발급을 통해 공증토록 하고 전자상거래시 거래당사자는 인증기관의 인증서를 확인함으로써 상대방의 정당성을 확인할 수 있도록 함 → 인증기관의 설립 필요 고객 인증서 : 고객의 서명용 인증서만 발급 판매자 인증서 : 판매자의 서명용인증서와 키교환용 인증서를 쌍으로 발급 지급정보중계기관 : 서명용인증서와 키교환용 인증서를 쌍으로 발급 48

49 SET에서의 프로토콜 (14) 49

50 SET에서의 프로토콜 (15) 인증서 발급절차 고객/판매자/지급정보중계기관의 인증기관은 상위인증기관으로부터 동 인증권한 및 인증서를 부여받음(이때 상위인증기관의 구성은 가변적임) 피인증기관은 해당금융기관에 사전등록된 비밀번호등의 결제 또는 판매자정보를 등록 양식에 입력하여 인증기관에 인증서 발급요청 인증기관은 해당 금융기관으로 결제 또는 판매자정보를 송신하여 인증서발급 승인여부를 조회 ※ 고객과 금융기관간의 중요결제정보가 인증기관에 노출 해당 금융기관은 온라인 수신된 정보와 자체시스템 DB에 사전등록된 정보와의 일치여부 판단 해당 금융기관은 비교 결과를 근거로 인증서발급 승인여부를 통보 인증기관은 해당 금융기관의 통보내용을 근거로 인증서발급 발급 또는 거부 50

51 SET에서의 프로토콜 (16) 인증서 확인절차 전자상거래 상대방의 인증서를 해당 인증기관의 공개키로 복호화하여 거래상대방의 공개키를 획득한 후 동 공개키를 이용하여 거래상대방의 전자서명을 확인한 결과가 일치할 경우 해당 거래당사자를 인증기관이 인정한 정당거래자로 처리함. 이때 인증기관의 공개키 획득 및 확인절차는 다음과 같음 인증서의 정당성 여부를 확인하기 위해서는 인증서를 발급한 인증기관의 공개키가 필요하고 이 경우 다시 해당인증기관의 공개키의 정당성을 보장하는 것이 문제가 됨. 따라서 SET 에서는 위의 그림과 같이 전자상거래 참여자에게는 최상위 인증기관에 대한 공개키(Root Key) 만을 공개하고 해당 인증기관의 정당성을 최상위 공개키(Root Key)로서 관계된 인증기관(Trust Chain)의 인증서를 단계적으로 풀어나감(Traverse)으로써 확인토록 조치함. 이때 최상위 공개키(Root Key)는 SET을 구현한 소프트웨어에 선 등록 조치가 필요함 51

52 SET에서의 프로토콜 (17) 52

53 SET에서의 프로토콜 (18) SET에서의 인증서 발급체계 SET에서 제공하는 신뢰계층에서 Root는 전세계적으로 동일
Visa, Master등의 Brand계층에 대한 인증을 제공 Brand는 각 Brand의 지역별 관리국인 Geo-political의 인증을 제공 Geo-political은 각 발급사와 매입사에 대한 인증을 제공 최상위 공개키를 생성한 기관은 필요시 모든 전자상거래 관련정보의 복호화가 가능하게 됨 53

54 SET에서의 프로토콜 (19) 54

55 SET의 거래처리절차 (1) 55

56 SET의 거래처리절차 (2) 고객은 인터넷상의 판매자에 접속하여 쇼핑한후 해당 판매자의 정당성을 확인시켜주는 판매자 및 지급정보중계기관(이하 'PG')의 인증서 수신 고객은 판매자와 PG 인증서를 확인하여 정당한 경우 상품주문 및 결제정보와 자신의 인증서를 송부함으로써 구매요청을 함 판매자는 고객인증서를 확인하여 정당한 경우 고객이 암호화한 결제정보를 이용하여 해당 PG에게 승인요청하고 동시에 고객에게 구매응답전문을 송신 PG는 고객과 판매자의 인증서를 확인하여 정당한 경우 결제정보를 해당 금융기관이 이용가능한 내부 FORMAT으로 변환하여 승인요청을 함 ※ 고객의 결제관련 정보가 PG에 노출됨 56

57 SET의 거래처리절차 (3) 해당 금융기관은 고객의 신용한도를 고려하여 승인여부를 전송
PG는 해당전문을 SET FORMAT으로 변환하여 판매자에게 전송 판매자는 PG의 응답전문에 의거하여 해당고객에 영수증 및 물품을 인도 PG는 판매자와 고객은행간의 정상처리분에 대한 결제요청 처리를 실시 57

58 거래 및 결제처리 과정 (1) 구 매(Purchase Request) 58

59 거래 및 결제처리 과정 (2) 고객 요청 개시 고객 쇼핑
고객 소프트웨어는 판매자에게 첫 요청전문(Initiate Request) 전송 판매자 인증서 전송 판매자 소프트웨어는 첫 요청전문 수신 판매자 소프트웨어는 응답전문(Initiate Response)을 생성하여 전자서명 수행(응답전문의 메세지다이제스트을 생성하여 판매자의 서명용 개인키로 암호화함) 판매자 소프트웨어는 고객에게 판매자와 지급정보 중계기관(이하 PG)의 인증서, 구매 트랜젝션 고유로 생성되는 트랜젝션 ID를 응답전문과 함께 전송 59

60 거래 및 결제처리 과정 (3) 고객 응답전문 수신 및 구매요청전문(Purchase Request) 전송
고객 소프트웨어는 첫 응답전문을 수신하고 루트키에 대한 신뢰계층(Trust Chain)에 의해 판매자와 PG인증서 검증 고객 소프트웨어는 판매자의 서명 검증(판매자의 서명용 공개키로 복호화하고 응답전문에 대해 새로 생성된 해쉬와 그 결과를 비교함) 고객 소프트웨어는 쇼핑시 획득한 정보를 사용하여 주문정보(OI) 생성 고객은 결제지시전문(PI) 작성 고객 소프트웨어는 이중서명 생성(주문정보(OI)와 결제지시전문(PI) 각각의 메시지다이제스트 M1, M2를 연결(M1M2)한 후 다시 새로운 메세지다이제스트(M)를 생성하고, 이 이중해쉬를 고객의 서명용 개인키로 암호화함) 고객 소프트웨어는 임의로 생성된 비밀키(#1)로 결제지시전문(PI)을 암호화(이중서명, M1M2까지 포함하여)하고 이 키는 고객의 금융정보와 함께 지급정보 중계기관의 키교환용 공개키로 암호화하여 전자봉투 생성 고객 소프트웨어는 이중서명, M1M2, 주문정보(OI), 암호화된 결제지시전문(PI), 전자봉투, 고객 인증서를 판매자에게 전송 60

61 거래 및 결제처리 과정 (4) 판매자 요청 메세지 처리 판매자 소프트웨어는 루트키 신뢰계층에 의해 고객의 인증서검증
판매자 소프트웨어는 주문정보에 대한 고객의 이중서명 검증 판매자의 승인요청전문 전송(Request Authorization) - 승인을 위해 PG로 결제지시전문(PI)을 전송 판매자 소프트웨어는 구매응답전문(Purchase Response)을 생성하고 전자서명함(구매응답전문의 메세지다이제스트를 생성하고 판매자의 서명용 개인키로 암호화) 판매자 소프트웨어는 고객에게 구매응답전문, 전자서명, 판매자의 서명 인증서 전송(고객에게 응답을 전송하기 전에 결제승인을 받을 필요는 없음) 거래가 승인되면 판매자는 상품을 전달함으로써 고객의 주문 이행 61

62 거래 및 결제처리 과정 (5) 고객의 구매응답전문 수신 고객 소프트웨어는 루트키의 신뢰계층에 의해 판매자의 서명 인증서 검증
고객 소프트웨어는 판매자의 전자서명 검증(판매자의 서명용 공개키로 복호화하여 새로 생성된 구매응답전문의 해쉬와 비교함) 고객 소프트웨어는 응답내용을 디스플레이하고 구매응답전문 저장 ※ 고객은 구매조회전문(Order Inquiry message)을 전송함으로써 구매승인 여부와 같은 구매관련 내용의 조회가 가능 62

63 거래 및 결제처리 과정 (6) 결제 승인(Payment Authorization) 63

64 거래 및 결제처리 과정 (7) 판매자 승인 요청(Authorization Request)
판매자 소프트웨어는 트랜젝션 ID, 기타 트랜젝션 관련정보를 포함하는 판매대금결제요청전문(Authorization Request) 생성 판매자 소프트웨어는 판매대금결제요청전문에 대해 전자서명 수행(판매대금결제요청에 대한 메세지다이제스트를 생성하고 판매자의 서명용 개인키로 암호화함) 판매자 소프트웨어는 임의로 생성된 비밀키(#2)로 전자서명이 포함된 판매대금결제요청전문을 암호화하고 이 키는 PG의 키교환용 공개키로 암호화하여 전자봉투 생성 판매자 소프트웨어는 암호화된 판매대금결제요청전문과 ㉢에서 생성된 전자봉투, 고객의 구매요청전문에서 획득한 암호화된 결제지시전문(PI)과 전자봉투, 고객 서명 인증서, 판매자 서명 인증서, 판매자 키교환 인증서를 PG에게 전송 64

65 거래 및 결제처리 과정 (8) 지급정보 중계기관(PG) 승인 요청 처리
PG는 루트키의 신뢰계층(Trust Chain)에 의해 판매자의 인증서 검증 PG는 자신의 키교환용 개인키로 ㉢에서 생성된 전자봉투를 복호화하여 비밀키(#2)를 획득하고 이 비밀키(#2)를 사용하여 판매대금결제요청전문 복호화 PG는 판매자의 전자서명 검증(판매자의 서명용 공개키로 전자서명을 복호화하고 판매대금결제요청전문에 대해 새로 생성된 해쉬를 비교함) PG는 루트키의 신뢰계층에 의해 고객의 인증서 검증 PG는 자신의 키교환용 개인키로 판매자를 통해 고객으로부터 전송되어온 전자봉투를 복호화하여 비밀키(#1)와 고객의 금융정보를 획득하고 이 비밀키(#1)를 사용하여 결제지시전문(PI) 복호화 65

66 거래 및 결제처리 과정 (9) PG는 결제지시전문(PI)에 대한 고객의 이중서명 검증(새로 생성된 결제지시전문의 메시지다이제스트 M2를 수신된 M1M2의 M2와 대체하고 M1M2에 대한 새로운 메시지다이제스 M을 생성하여, 고객의 서명용 공개키로 이중서명을 복호화한 M과 비교함) PG는 판매자의 판매대금결제요청전문과 고객의 결제지시전문(PI)사이의 일치성 확인 PG는 금융망을 통해 고객의 금융기관과 판매대금결제지시전문 및 판매대금결제승락/거부보고전문을 송·수신 PG는 판매대금승락/거부통보전문(Authorization Response)을 생성하여 전자서명 수행(판매대금승락/거부통보전문에 대한 메세지다이제스트를 생성하고 중계기관의 서명용 비밀키로 암호화함) PG는 임의로 생성된 비밀키(#3)로 판매대금승락/거부통보전문을 암호화하고 이 키는 판매자의 키교환용 공개키로 암호화하여 전자봉투 생성 66

67 거래 및 결제처리 과정 (10) PG는 임의로 생성된 비밀키(#3)로 판매대금승락/거부통보전문을 암호화하고 이 키는 판매자의 키교환용 공개키로 암호화하여 전자봉투 생성 PG는 결제처리토큰(Capture Token) 생성(매입사에 따라 생성여부 결정) PG는 임의로 생성된 비밀키(#4)로 결제처리토큰(Capture Token)을 암호화하고 이 키와 고객의 금융정보를 PG의 키교환용 공개키로 암호화하여 전자봉투 생성 PG는 ㉩, ㉫의 결과, PG의 서명 인증서를 판매자에게 전송 ※ 결제처리토큰(Capture Token)은 매입사의 방침에 따라 생성 및 사용여부를 결정하며, 이후 언급되는 결제처리토큰관련 절차는 그 생성을 전제로 한 것임 67

68 거래 및 결제처리 과정 (11) 판매자 응답 처리 판매자 소프트웨어는 루트키의 신뢰계층에 의해 PG인증서 검증
판매자 소프트웨어는 PG의 전자서명 검증(PG의 서명용 공개키로 복호화하고 판매대금결제승락/거부통보전문에 대해 새로 생성된 해쉬를 비교함) 판매자는 다.결제처리과정(Payment Capture)을 위해 암호화된 결제처리토큰(Capture Token)과 ②-㉫에서 생성된 전자봉투 저장 승인된 거래인 경우 판매자는 상품을 전달함으로써 고객의 주문 이행 68

69 거래 및 결제처리 과정 (12) 결제 처리(Payment Capture) 69

70 거래 및 결제처리 과정 (13) 판매자 결제처리요청 판매자 소프트웨어는 결제처리요청전문(Capture Request) 생성
판매자 소프트웨어는 결제처리요청전문에 전자서명(결제처리요청전문의 메세지다이제스트을 생성하여 판매자의 서명용 비밀키로 암호화함) 판매자 소프트웨어는 임의로 생성된 비밀키(#5)로 결제처리요청전문을 암호화하고 이 키는 PG의 키교환용 공개키로 암호화 판매자 소프트웨어는 암호화된 결제처리요청전문, 전자서명, 판매자 서명 인증서, 결제승인과정(Payment Authorization)에서 전송받은 암호화된 결제처리토큰(Capture Token) 및 전자봉투도 함께 전송 70

71 거래 및 결제처리 과정 (14) 지급정보 중계기관(PG) 결제처리요청 처리
PG는 루트키의 신뢰계층(Trust Chain)에 의해 판매자의 인증서 검증 PG는 자신의 키교환용 개인키로 전자봉투를 복호화하여 비밀키(#5)를 획득하고 이 비밀키(#5)를 사용하여 결제처리요청전문 복호화 PG는 판매자 전자서명 검증(판매자의 서명용 공개키로 복호화하고 새로 생성된 결제처리요청전문의 해쉬와 비교함) PG는 결제승인과정(Payment Authorization)에서 생성된 전자봉투를 자신의 키교환용 개인키로 복호화하여 비밀키(#4)를 획득하고 동 비밀키(#4)를 사용하여 결제처리토큰(Capture Token) 복호화 71

72 거래 및 결제처리 과정 (15) PG는 판매자의 결제처리요청전문과 결제처리토큰사이의 일치성 확인
PG는 결제처리응답전문(Capture Response)을 생성하여 전자서명(결제처리 응답전문의 메세지다이제스트를 생성하여 PG 서명용 비밀키로 암호화함) PG는 임의로 생성된 비밀키(#6)로 결제처리응답전문을 암호화하고 이 키는 판매자의 키교환용 공개키로 암호화하여 전자봉투 생성 PG는 암호화된 결제처리응답전문, 전자서명, 전자봉투를 판매자에게 전송 72

73 거래 및 결제처리 과정 (16) 판매자 응답전문 수신 판매자 소프트웨어는 루트키의 신뢰계층에 의해 PG의 인증서 검증
판매자 소프트웨어는 판매자의 키교환용 개인키로 전자봉투를 복호화하여 비밀키(#6)를 획득하고 이 비밀키(#6)를 사용하여 결제처리응답전문 복호화 판매자 소프트웨어는 PG의 전자서명 검증(PG의 서명용 공개키로 복호화하고 새로 생성된 결제처리응답전문의 해쉬와 비교함) 판매자 소프트웨어는 매입사와 결제에 관련된 분쟁발생시 사용하기 위하여 결제처리응답전문을 저장 ※ 다. 결제처리(Payment Capture)과정은 주로 Batch로 처리될 예정이며, 결제처리 요청전문의 전송은 Header, Detail, Trailer의 레코드로 이루어진 파일형식을 사용하여 전송함 73