SET(Secure Electronic Transaction) 총정리

1. SET의 개념

SET 프로토콜, 이른바 보안 전자 거래는 시나리오에서 신용 카드를 사용하여 수행되는 전자 거래의 보안과 무결성을 보장하는 시스템이다. 여기서 확실히 해야 할 것은, SET는 결제를 가능하게 하는 시스템이 아니라, 해당 결제에 적용되는 보안 프로토콜이라는 점이다. 다양한 암호화 및 해싱 기술을 사용하여 신용 카드를 통해 이루어지는 인터넷 결제를 보호한다. SET 프로토콜은 Visa, Mastercard, STT(Secure Transaction Technology)를 제공하는 Microsoft, SSL(Secure Socket Layer) 기술을 제공하는 Netscape와 같은 주요 조직의 개발을 지원했다.

SET 프로토콜은 신용 카드 정보가 판매자에게 공개되는 것을 제한하여 공격을 가능한 방지하고자 한다. SET 프로토콜에는 X.509 인증서와 같은 표준 디지털 인증서를 사용하기 위한 인증 기관이 포함되어 있다. 

SET에 대해 더 자세히 논의하기 전에 고객, 지불 게이트웨이, 고객 금융 기관, 가맹점 및 가맹점 금융 기관을 포함하는 전자 거래의 일반적인 시나리오를 살펴보면 다음과 같다.

 

즉, SET는 고객(카드 소지자), 발행자(고객 금융기관), 가맹점(상인), 가맹점 금융기관, 인증 기관이 참여하는 것이다.

 

2. SET의 요구사항

SET 프로토콜에는 충족해야 할 몇 가지 요구사항이 있으며, 중요한 요구사항 중 일부는 다음과 같다. 

① 고객이 의도된 사용자인지 아닌지를 확인하는 상호 인증, 즉 고객(또는 카드 소지자) 인증과 가맹점 인증을 제공해야 한다.
② 적절한 암호화를 통해 PI(결제 정보)와 OI(주문 정보)를 기밀로 유지해야 한다.
③ 메시지 수정에 대해 저항력이 있어야 한다. 즉, 전송되는 콘텐츠에 어떠한 변경도 허용되어서는 안 된다.
④ SET는 또한 상호 운용성을 제공하고 최상의 보안 메커니즘을 활용해야 한다.

 

3. SET에서 제공하는 기능

① 인증 제공
ㄱ. 판매자 인증 – 도난 방지를 위해 SET를 통해 고객은 판매자와 금융 기관 간의 관계를 확인할 수 있다. 확인을 위한 과정에는 표준 X.509 인증서가 사용된다.
ㄴ. 고객(카드 소지자) 인증 – SET는 승인된 사용자가 신용 카드를 사용했는지, X.509 인증서를 사용하지 않았는지 확인한다.

②메시지 기밀성 제공: 여기서 기밀성이란 전송되는 메시지를 의도하지 않은 사람이 읽지 못하도록 방지하는 것을 의미한다. SET는 암호화 기술을 사용하여 기밀성을 구현한다. 전통적으로 DES가 암호화 목적으로 사용되곤 했다.
③ 메시지 무결성 제공: SET는 서명을 통한 메시지 수정을 허용하지 않는다. 메시지는 SHA-1이 포함된 RSA 디지털 서명을 사용하고, 일부는 SHA-1이 포함된 HMAC를 사용하여 무단 수정으로부터 보호된다.
④ 이중 서명: 이중 서명은 SET에 도입된 개념으로, 두 개의 서로 다른 수신자를 위한 두 개의 정보 조각을 연결하는 것을 목표로 하는 것이다.
ㄱ. 가맹점 주문정보(OI)  
ㄴ. 은행 결제정보(PI) 

혹자는 각 정보를 별도로 보내는 것이 더 쉽고 안전한 방법이라고 생각할 수도 있을 것이다. 하지만 연결된 형식으로 보내는 것이 향후 발생할 수 있는 모든 분쟁을 해결한다. 따로 보내기에 생길 수 있는 문제가 있다는 점을 인지해야 한다. 그리고 이중 서명의 생성은 다음과 같다.

 

⑤ 구매요청

한편, 구매요청 생성 프로세스에는 3가지 입력이 필요하다. 결제 정보(PI), 이중 서명(Dual Signature), 주문 정보 메시지 다이제스트(OIMD)가 필요하다.

이 3가지가 더해진 것이 대칭키 암호화(EP)되어 디지털 봉투(Digital Envelope), 결제정보 메시지 다이제스트(PIMD), 주문정보(OI), 이중 서명, 고객 인증서(CA)와 더해지고 그것을 판매자가 수신하게 되는 것이다.

 

⑥ 가맹점 측 구매요청 검증

가맹점 측 구매요청 검증의 경우, 가맹점은 결제정보 메시지 다이제스트(PIMD) 해싱(H)을 통해 생성된 지불주문 메시지 다이제스트(POMD)와 이중서명 복호화를 통해 생성된 지불주문 메시지 다이제스트(POMD)를 비교대조하여 검증하게 된다. 여기서는 암호화에 고객의 개인 키를 사용했기 때문에 복호화(D)를 위해 고객(카드 소지자)의 공개 키인 KUc를 사용한다. 위 그림에서 ∥는 추가작업을 의미한다.

 

⑦ 지불 승인 및 지불 수집

이름에서 알 수 있듯, 지불 승인은 판매자가 지불을 받을 수 있도록 판매자가 지불 정보를 승인하는 것이다. 지불 수집은 판매자가 지불을 받는 프로세스로, 게이트웨이에 대한 일부 요청 블록을 다시 생성하고 지불 게이트웨이가 판매자에게 지불을 발행하는 것을 포함한다.

 

4. SET의 단점

1996년 SET이 처음 제시됐을 당시만 하더라도 몇 년 안에 SET이 일반적으로 채택될 것이라는 전망이 있었다. 겉보기엔 너무 좋아 보여서 즉시 전 세계의 비즈니스를 강화하는 핵심으로 자리잡을 것으로 예상된 것이다. 그런데 SET에는 심각한 취약점이 존재했음이 밝혀지며 당초에 예상했던 만큼의 영향까지는 미치지 못하게 되었다.

 

SET의 보안 속성은 특히 웹 기반 비즈니스 강탈을 방지하는 능력 면에서 분명 SSL/TLS보다 우수하다. 그러나 SET의 가장 큰 단점은 바로 복잡하다는 것이다. SET는 두 명의 클라이언트와 트레이더가 특별한 프로그래밍(카드 열람자와 고급 지갑)을 도입하도록 요구한다. 이는 거래소 회원이 SET를 수행하기 위해 더 많은 작업을 완료해야 함을 의미한다. 마찬가지로 이러한 복잡성으로 인해 웹 기반 비즈니스 교환 속도가 느려졌다. SSL과 TLS에는 이러한 문제가 없는데 말이다. 아무리 보안 측면에서 우수하더라도, 사람인 이상 빠르고, 편리한 것을 더 선호할 수밖에 없다. 그게 실질적인 사용 측면에서 SET가 큰 영향을 발휘하지 못하는 이유가 되는 것이다.

또한, PKI와 관련된 사항 및 등록 프로세스로 인해 SET의 광범위한 수신이 추가로 느려졌다. SET 항목 간의 상호 운용성도 마찬가지로 SET에서 큰 문제였다. 결국 SET의 가장 큰 단점은 '편의성'이라고 말할 수 있겠다.