SET(Secure Electronic Transaction)

SET(Secure Electronic Transaction) 이란?

SET(Secure Electronic Transaction)이란 간단히 말해 전자상거래에서 지불정보를 안전하고 비용효과적으로 처리할 수 있도록 규정한 프로토콜을 말합니다. 인터넷과 같은 공개된 통신망에서 전자상거래를 하기위한 "지불시스템에 대한 기술표준" 으로 S/W 와 H/W를 포함합니다.

1997년 5월 31일 신용카드 업계의 Major들인 Master와 Visa가 공동으로 발표하였으며 기술자문역으로 GTE, IBM, Microsoft, Netscape, Terisa, VeriSign, RSA, SAIC가 참여하여 SET 1.0을 개발 하였습니다.

SET(Secure Electronic Transaction)은 전자상거래시 안전한 지불을 위한 내용을 담고있습니다.
- 고객과 Merchant간에 서로의 신분을 확인할 수 있는 인증에 관한 내용
-인터넷 상에서 메세지를 안전하게 주고 받을 수 있는 암호화 기법에 관한 내용
-지불절차에 관한 내용

■SET의 구성

 

Cardholder:
Merchant에서 상품과 서비스를 구매하고 신용카드로 대금을 지불합니다.

Merchant:
Cyber Shopping Mall을 운영하는 주체로써 신용카드 가맹점입니다.

PG(Payment Gateway)
1. Merchant를 거쳐온 Cardholder의 지불명령을 처리합니다.
2. 국내에는 98년 12월 현재 시범운영 되고 있는 KCP가 유일합니다.

 

CA(Certificate Authority)
1. SET 참여자들의 신원을 확인하고 인증서를 발급합니다.
2. 국가마다 신용카드 브랜드별로 존재할 수 있으며 이들은 모두 기본(Root) CA에 의해 계층적으로 인증되고 관리됩니다.(NIC와 유사)
3. SET의 신뢰성 확보의 기반이 됩니다.

 

금융망
1. Issur - Cardholder에게 신용카드를 발급하고 합법적인 사용에 대해서 지불카드에 대한 지급을 보장합니다.
2. Acauier - Merchant와 가맹계약을 맺고 지불카드 승인과 전표매입을 수행합니다.
3. Brand - Issuer 및 Acquirer들과 제휴관계에 의해 각각의 Issuer/Acquirer를 연계합니다. Master나 Visa등이 이에 속합니다.

 

■SET의 동작
안전한 전자상거래를 하기 위해서는 인터넷을 통한 메세지에 대한 보안보장과 거래 당사자간의 신뢰보장입니다.

A. 메시지의 암호화
1. Cardholder의 계좌번호, 신용카드번호, 지불정보등의 민감한 정보의 노출을 방지하기 위해 메세지를 암호화 합니다.

2. 암호화 알고리즘은 대칭키(비밀키-128bit) 방식이며 키의 분배를 위해 RSA(공개키-1024bit) 방식을 사용합니다.

3. 대칭키는 거래때 마다 바뀌기 때문에 세션키라고도 부르며 키의 암호화와 복호화 방식이 같으므로 Cardholder는 이 키의 보안에 힘써야 합니다.

B. 전자증명서
1. 거래 당사자들간의 인증(구매자가 올바른 신용카드 회원인가, 상인이 올바른 가맹점 상인인가)을 위해 X.509를 기반으로 하는 전자 증명서(Certificate)를 발급 받아야 합니다.

2. 전자증명서는 인증국(Certificate Authority)에 의해 발행되며 이름, 신용카드의 이름, 암호키 일부등이 내용에 포함됩니다.

3. 유효기간은 최대 3년이며 유효기간이 지났거나 취소된 증명서에 대해서 거래를 거부합니다.

C. 디지털 서명
1. 메세지에 전자서명과 해쉬함수를 사용함으로써 수신자가 메세지의 무결성을 확인할 수 있습니다.

2. 거래 당사자가 모두 서명하는 이중서명(Dual Signature)방식을 사용함으로써 Merchant가 신용카드 정보를 엿볼 수 없으며 은행은 어떤 물품을 구입하였는지 알 수 없게 합니다.

 

■SET의 문제점 및 전망
98년 말 현재 전세계적으로 SET 기반의 전자상거래가 이루어 지는 곳은 없습니다. SET기반의 전자상거래가 이루어지기 위해서는 거대한 인프라 구축이 필요하나 각 이해 당사자들이 심한 의견 대립을 보이고 있으며 진행 속도도 느린것이 문제점입니다. 따라서 SET의 앞날은 불투명하다 할 수 있겠습니다.

그러나 EC가 폭발적으로 증가할 것이라는 전망에는 이견이 없으며 기존의 SSL,PGM등을 이용한 독자적인 상거래 시스템으로는 한계가 있다는 것 또한 사실입니다.
국내의 경우 KSP에서 PG를 구축하고 있고 몇개의 기업에서 산발적인 개발을 하고 있으나 불투명한 시장상황으로 본격적인 투자는 미루고 있는 실정입니다

  

  암호화 프로토콜 
    
  현재 암호화 Protocol로서 가장 활성화 되어 있는 것은 SSL(Secure Socket Layer)과 
  SET(Secure Electronic Transaction)입니다. 암호화 Protocol은 앞서 설명한 암호화 
  알고리즘과 이를 이용한 부인봉쇄, 기밀성, 상호인증, 전자 서명, 전자봉투등의 방법을 
  이용하여 정보보호 효과를 극대화 하기 위한 업무 Process를 정의하여 놓은 것입니다.
  SSL은 통신 Protocol의 Layer 계층에서 Data 암호화/복호화를 위한 Protocol입니다.
  SET는 응용프로그램 계층에서 주로 전자상거래의 지불정보를 완벽히 보호하기 위하여 
  고안된 Protocol입니다.
   
  가. SSL(SECURE SOCKET LAYER)
  전자상거래에서 많이 이용되는 SSL은 기본적으로 Data암호화를 위하여 Netscape사에서  개발 되었습니다. 따라서 사용자 인증없이도 Data 암호화가 가능하였습니다. 
왜냐하면, Web Brwoser의 기본인증(User ID와 Password 확인) 만으로도 업무처리가 가능하였기 때문입니다. 

 

그런데, 전자상거래의 폭발적인 증가로 User ID와 Password만으로는 정보보호에 한계가 있었습니다. 또한 Web Browser에 내장되어 있는 대칭키 알고리즘은 DES 40Bit를 사용 함으로서 암호의 강도가 약하고, Key의 배분문제 때문에 인증의 필요성이 대두되었습니다. 

이에 따라 인증체계의 도입과 보다 강력한 대칭키 암호 알고리즘이 필요하게 되었습니다. 
기본적으로 SSL은 Handshake Layer 단계와 Record Layer 단계를 거쳐 작동됩니다. 
Handshake Layer 단계에서는 client와 server간에 인증서 교환 및 상호 신원 확인, 암호화에 사용될 대칭키 (Session Key)를 교환하는 과정을 수행합니다.

 

Record Layer 단계에서는 교환된 대칭키를 가지고 암호화된 Socket을 이용하여 Data를 주고받는 과정을 수행합니다. 

SSL 환경을 설정하기 위해서는 다음과 같은 과정을 수행하여야 합니다. 
   
  1) 클라이언트는 보안 서버에 https://servername.domain.com과 같은 형태로 접속을 
  -- 요청합니다. 
   
  2) 서버는 클라이언트의 요청에 따라 자신의 인증서를 클라이언트에게 보냅니다. 
   
  3) 클라이언트는 서버의 인증서가 자신이 신뢰하는 인증기관에서 인증하였는지를 조사합니다.
   
  4) 클라이언트가 서버의 인증서를 신뢰한다면, 클라이언트가 서버에게 통신할 수 있는 암호화 
  -- 알고리즘의 종류를 알립니다.
   
  5) 서버는 클라이언트가 전송한 암호화 알고리즘중에서 가장 안전한 것를 선택한 후 이를
  -- 클라이언트에게 알려줍니다.
   
  6) 클라이언트는 선택된 암호화 알고리즘을 이용하여 Session Key(해당 트랜잭션에서만 
  -- 사용하는 대칭키)를 생성하고, 서버의 공개키로 이를 암호화 한 후 서버에게 전송합니다. 
   
  7) 서버는 클라이언트로부터 수신한 전자봉투를 복호화하여 Session Key를 획득합니다. 
   
  8) 클라이언트와 서버간에 대칭키가 교환되었으므로 Data 송수신시에 Session Key를 이용한 
  -- 암호화/복호화 과정을 통하여 안전한 통신을 할 수 있습니다. 
  -: 데이터 암호화 과정중에는 메세지를 압축한 MAC(Message Authentication Code:Hash
  -- 값)을 추가하여 이를 함께 암호화합니다. 이를 그림으로 나타내면 다음과 같습니다. 
    
이 러한 과정에 서버는 클라이언트의 인증서를 요구할 수 있습니다.

그러나 이러한 SSL의 간편성에도 불구하고, 다음과 같은 문제점들이 존재합니다. 
   
1) SSL은 응용프로그램과 독립적인 Protocol임에도 불구하고 현재 HTTP Protocol만을 지원 합니다. 따라서 FTP, Telnet등과 같은 여타 TCP/IP 통신환경의 Protocol은 지원하지 못합니다.
또한 SSL 작동을 위하여 Web Server에 대한 Customizing을 필요로 합니다. 

 특히 미국의 수출규제로 인하여 128Bit 대칭키 암호화 알고리즘의 Web Browser 탑재가 미국외에서 불가능하기 때문에 128Bir 암호화 알고리즘을 지원하는 gateway Product을 별도로 설치하여야 하는 번거로움도 있습니다.

 

이경우 대부분 SSL Proxy Controller를 사용하게 되는 데 이를 보통의 User들이 쉽게 사용하지 못하기 때문에 활성화가 안되는 요인이 되기도 합니다. 뿐만 아니라 Web Browser가 Cookie 기능을 사용하거나 Cache Memory 설정 등 복잡한 문제에 직면했을 때, User들이 이를 극복하는 데 많은 어려움을 겪기도 합니다. 
   
2) SSL은 기본적으로 Web을 기반으로 한 암호화 Protocol 이기 때문에 IP Spoofing등의 해킹에 취약할 수 있습니다. 특히 개인정보와 지불정보(User ID, 통장번호, 신용카드 등)가 서버에 전송되어야 하기 때문에 통신망에 대한 해킹, 시스템 내부자에 의한 정보유출등으로 개인정보가 외부로 노출될 가능성이 많습니다. 또한 C/S 환경에는 지원을 하지 않기 때문에 Applet이나 Active X Controller 등의 인터넷 응용프로그램의 보안을 지원하지 못합니다. 
   
3) 인증서와 개인키는 기본적으로 PC에 저장되어 관리되기 때문에 클라이언트의 이동성에 제약을 받습니다. 따라서 증권회사등 사용자의 특성에 따라서는 인증서를 사용치 않고, Data암호화만을 수행하는 경우가 많습니다.  
   
4) SSL 방식에 의한 전자상거래 표준이 마련되어 있지 않기 때문에 쇼핑몰, 인터넷 뱅킹, 기타 정보보호 Site의 암호화, 인증방식이 서로 상이합니다. 따라서 사용자 입장에서는 정보보호 Site별로 상이한 인증서와 암호화 프로그램을 각각 설치하여야 하는 불편을 감수하여야 합니다. 
   
5) 현재의 제품화 기술 수준으로는 Data처리 속도가 매우 늦고, 사용자가 많은 불편함을 감수하여야 합니다. 즉 모든 Data를 암호화 하기 때문에 그래픽이나 이미지, 동영상과 같은 많은 Byte수를 처리하는 데에는 처리속도가 매우 늦을 수 밖에 없으며, 따라서 대부분 HTTPS Mode는 Text위주로 구성되어 있습니다. 
   
나. SET(SECURE ELECTRONIC TRANSACTION)

SET(Secure Electronic Transaction)는 인터넷을 이용한 전자상거래에서의 안전한 지급 결제를 위하여 비자와 마스터카드사가 공동으로 개발한 신용/직불카드결제를 위한 보안프로토콜입니다.

97년 3월 Protocol이 발표된 이후 전세계적으로 SET Product을 개발한 회사는 손꼽을 만큼 Protocol의 구현이 어렵고 내용이 방대하기 때문에 이를 개발하였다는 것은 정보보호 Solution 개발능력 자체를 인정할 수 있는 것과 같습니다.

 

그러나 SET와 관련된 동향을 살펴보면,  그 정보보호 기술의 우수성과 체계성에도 불구하고, SET 구성요소간의 시스템적, 제도적 INFRA의 구축이 미비하고 이를 적용하고자 하는 신용카드 회사들의 준비 부족, SET 1.0 Version의 일부기능 미지원 이유로 활성화되는 데에는 적지않은 노력이 필요할 것으로 판단됩니다.

 

즉, SSL 방식은 클라이언트와 서버간의 약정만 맞으면 개인정보의 제공 유무에 관계없이 거래를 개시할 수 있으나, SET방식은 계층별 CA, card Holder, Merchant, Payment GateWay, Issuer, Bank등 참여 주체간의 제도적 합의와 각종 기준이 마련되어야만 제 기능을 다할 수 있습니다.

그럼에도 불구하고, SET Protocol이 제시한 암호화 방법과 신원증명 기능은 SSL의 개념보다 분명히 강화된 정보보호 기술을 보장합니다. 
   
  ○ 기존 전자상거래가 전자상거래의 업무특성에 맞게 별도로 개발된 Application Level의 보안 
  프로토콜을 적용하지 않고, 단순 홍보자료 제공업무등을 포함한 인터넷을 이용하여 처리되는 
  모든 업무에 대해 공통적으로 적용되고 있는, 즉, 상위 계층(Layer)의 업무특성 및 중요도에 
  관계없이 단순 인터넷 접속 및 전송시의 안정성을 위해 운영되고 있는 Transport Level의 
  SSL(Secure Socket Layer) 보안프로토콜만을 이용하여 전자상거래를 함으로써 인터넷 이용
  업무중 상대적으로 안정성이 중요시되는 전자상거래 업무의 보안성이 취약한 상태입니다. 
   
  ○ 전자상거래를 위한 표준 전문프로토콜이 없이 각 쇼핑몰 운영을 원하는 기관 또는
  전자상거래용 소프트웨어를 개발하는 개발사의 특성에 맞게 고객 인증 및 구매.결제 처리기능을
  통합 개발하여 운영함으로써 전자상거래 이용 고객의 불편야기 및 전자상거래 비활성화를
  초래할수도 있습니다.
   
  1) SET의 개요
  - SET 개념
  SET(Secure Electronic Transaction)은 인터넷을 이용한 전자상거래에서의 안전한 지급결제
  수단을 제공하기 위하여 비자와 마스터카드사가 공동으로 개발한 신용/직불 카드결제용 전문 
  및 보안 프로토콜로써 전자상거래 판매업자, 고객, 지급정보 중계 기관간 상호인증, 거래정보의
  기밀성 및 무결성을 최대한 보장하도록 설계되었고, 전자상거래 활성화를 위해 국제표준을
  목표로 하고있습니다.
   
  - SET에서의 보안 서비스
  SET에서는 개방된 네트워크에서 보안대책에 필수적인 다음과 같은 보안서비스를 제공합니다.
 

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

  한편 SET에서는 전자상거래 참여자간의 데이터 송수신에 필요한 보안사항만 규정하고 있는
  관계로 부적격자에 의한 내부 시스템으로의 침입등을 방지하기 위한 시스템 보안 대책(FIRE-
  WALL구축등)은 해당기관에서 별도 수립 및 시행을 하여야 합니다.
   
  2) SET의 적용범위
  SET은 전자상거래에 필요한 여러 처리절차중 카드를 이용한 지급결제처리절차에 한해 
  정의하고 있으므로 상품선택, 배송방법 등 지급결제 관련 이외의 처리절차와 현금, 수표 등 
  카드이외의 결제수단에 대해서는 별도의 정의가 필요합니다. 비자와 마스터사는 현금, 수표 등 
  카드 이외의 결제수단에 대한 처리절차를 정의 하기 위한 Super-SET과 SET에 IC카드를 
  접목하기 위한 C-SET을 별도로 준비중입니다.
   
  3) SET의 구성요소 

    
  ㅇ 고객(Cardholder) : 인터넷쇼핑몰에서 물품 또는 서비스를 구매하는 자 
  ㅇ 판매자(Merchant) : 인터넷상에서 상품이나 서비스를 제공하는자
  ㅇ 발급사(Issuer) : 고객의 카드발급 금융기관 혹은 결제카드 소지인의 계좌가 개설되어 있는
  -- 금융기관
  ㅇ 매입사(Acquirer) : 판매자의 가맹점 승인 금융기관 혹은 판매자의 계좌가 개설되어 있는
  -- 금융기관
  ㅇ 지급정보 중계기관(Payment Gateway) : 판매자가 요청한 고객의 지급정보로 해당
  -- 금융 기관에 승인 및 결제를 요청하는 기관
  ㅇ 인증기관(Certification Authority) : 고객 및 판매자 등 각 참여기관이 인터넷 상에서 서로
  -- 신뢰하면서 거래할 수 있도록 각 참여기관에게 전자적인 인증서를 발급하는 기관
   
  4) SET의 정보보호 Protocol
  - 기본적인 암호화 알고리즘
  ① 대칭키(비밀키) 암호화 알고리즘 : 데이터 암호화/복호화에 사용 데이터 송신자가 임의 생성
  ② 비대칭키(공개키) 암호화 알고리즘 : 비밀키 교환을 위한 전자봉투 생성, 메세지
  -- 다이제스트에 대한 전자서명시 사용 공개키는 개인키 소유자가 생성후 인증서를 발급받아
  -- 거래상대방에게 교부

  ☞ 메세지 암호화/복호화는 처리속도가 빠른 비밀키를 이용하고, 공개키는 메세지 축약문서에
  -- 대한 암호화(전자서명) 및 비밀키 교환을 위한 전자봉투(비밀키 암호화) 생성에 이용 
  -- 함으로서 공개키 암호화 알고리즘의 약점인 처리속도 지연문제를 해결 
  ③ 전자봉투 : Technology의 전자봉투 참조
  ④ 전자서명 : Technology의 전자서명 참조
   
  - 보안 Protocol 
  ㅇ 기밀성, 무결성, 인증, 부인봉쇄 등의 서비스제공을 위한 SET의 기본 프로토콜로서 인증서
  -- 발급, 구매 등 보안이 필요한 전문 송수신시 적용됨 
  ㅇ 본 기본 프로토콜을 수행하는데 필요한 수신인의 키교환용 공개키는 본 절차 수행전
  -- 단계에서 수신 및 검증완료됨. 
    
  < 암호화 및 송신절차 > 
  ① 송신인의 고유정보(Property)에 일방향 해쉬함수를 적용하여 메세지 다이제스트생성 
  ② 송신인의 비밀서명키로 메시지 다이제스트를 암호화하여 디지탈서명 생성
  ③ 비밀키를 임의로 생성(Secret Key Random Generate)
  ④ 고유정보, 디지털 서명, 송신자의 서명용 공개키가 들어있는 인증서 사본을 ③에서 생성된 
  -- 비밀키로 암호화
  ⑤ ④에서 사용한 비밀키를 수신인의 키교환 공개키로 암호화함으로써 전자봉투(Digital 
  -- Envelope) 생성 (송신인은 사전에 수신인의 키교환 공개키가 포함된 인증서를 가지고 있음)
  ⑥ 송신인은 ④의 결과와 ⑤의 결과를 수신인에게 전송함 < 수신 및 복호화 절차 >
  ⑦ 수신인은 메세지를 수신후 우선적으로 전자봉투를 자신의 키교환비밀키로 복호화하여 
  -- 비밀키를 획득함
  ⑧ ⑦에서 획득한 비밀키를 이용 ④번의 암호문을 복호화함으로써 송신된 고유정보, 디지탈 
  -- 서명, 인증서의 평문정보를 알아냄
  ⑨ 송신인의 인증서에 포함되어 있는 송신인의 서명용 공개키로 디지털 서명을 복호화함으로써
  -- 송신인이 작성한 메시지 다이제스트 값을 알아냄 
  ⑩ ⑧에서 얻은 고유정보에 송신인이 사용한 동일한 일방향 해쉬함수를 사용하여 새로운
  -- 메세지 다이제스트를 생성하고 ⑨에서 얻은 메시지 다이제스트와 비교하여 동일한 경우에만 
  -- 정상적인 처리를 진행함 
  -- → 기밀성, 무결성, 상대방인증, 부인봉쇄의 보안서비스 가능
   
  - 이중서명(Dual Signature) 프로토콜 
  1) 필 요 성 
  SET에서는 고객의 결제정보가 판매자를 통하여 해당 지급정보중계기관(이하 'PG')으로
  전송됨에따라 고객의 결제정보가 판매자에게 노출될 가능성과 판매자에 의한 결제 정보의 
  위.변조의 가능성이 있으므로, 판매자에게 결제정보를 노출시키지 않으면서도 판매자가 해당 
  고객의 정당성 및 구매내용의 정당성을 확인 할 수 있고 PG는 판매자가 전송한 결제요청이 
  실제고객이 의뢰한 전문인지를 확인할 수 있도록 하는 이중서명 기술 도입이 필요하게 되었음.
   
  2) 처리 흐름도  
    
  ① 고객의 이중서명 생성 
  ㉠ 구매정보 OI에 대해 Hash함수를 적용하여 160 비트의 메시지 다이제스트 M1을 생성
  ㉡ 결제정보 PI에 대해 Hash함수를 적용하여 160 비트의 메시지 다이제스트 M2를 생성
  ㉢ 생성된 두개의 메시지다이제스트 M1,M2를 연접(Concatenation)한 후 연접된 결과에 
  -- Hash함수를 적용하여 메시지 다이제스트 M을 생성 
  ㉣ M에 고객의 개인키로 전자서명 

  ② PG에게 전해질 전자봉투 생성 및 필요데이타의 판매자앞 전송 
  ㉠ 비밀키를 Random Generate하여 결제정보(PI)를 암호화 시킨후 해당키를 PG의 공개키로
  -- 암호화하여 전자봉투 생성 
  ㉡ 구매정보, 암호화된 결제정보, M1M2, 고객의 전자서명, 전자봉투를 판매자에게 전송

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

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