암호를 이용한 전자상거래 - 신용카드 결제

●전자 지불 시스템

 ->신용카드 결제

 ->전자 화폐

 

이번 글에서는 신용카드 결제에 관련하여 깊게 공부해 보겠습니다.

 

전자지불형태에는 선불형(선불카드),직불형(계좌이체),후불형(신용카드,휴대폰 소액결제)가 있습니다.

이 중에서 신용카드는 신용카드 번호를 판매자에게 제공하면, 신용카드사들로부터 지급받고 신용카드사가 구매자에게 청구하는 형식입니다.

 

결제대금을 현재 전자자금결제대행업체(PG:payment gateway)에서 하는데요 예로 KG이니시스,LG U+등이 있습니다.

 

온라인 신용카드 결제 시나리오는 다음과 같습니다.

이용자가 인터넷 쇼핑몰에 상품주문, 결제정보를 전송하면 쇼핑몰에서는 PG에게 결제정보를 전송하고 거래승인을 요청합니다. 그러면 PG는 신용카드사로 결제정보를 전송하고 거래승인을 요청합니다. 승인을 받으면 그 결과는 PG를 거쳐 쇼핑몰에게도 승인의 결과가 가게되며 이용자는 주문결과와 거래승인번호를 받게 됩니다. 이용자가 상품을 받은 뒤 배송확인통보를 쇼핑몰과 PG에게 하게 되고 PG는 신용카드사로부터 매출전표매입요청을 하게됩니다.카드사는 가맹점입금대금지급을 해주고 PG는 쇼핑몰에게 정산을 지급합니다. 그후로 신용카드사는 이용자에게 대금결제요청을 하게되고 이용자는 대금결제를 합니다.

 

여기서 PG가 많이 생소하다고 생각되는데 이는 지불 게이트웨이 방식입니다. 쇼핑몰과 은행 또는 카드사를 연결해 거래 승인을 받는 시스템 혹은 대행회사입니다. 대표적으로 KG이니시스가 있습니다.

 

KG이니시스는 모든 신용정보를 데이터 암호화하는데  대칭키 128bit 키를 사용합니다. 그리고 RSA 전자 서명을 사용합니다.(우리나라 암호시스템의 키 사이즈도 작고 그렇게 안전하지 않다는 것을 알 수 있습니다..)

 

최초의 온라인 쇼핑이라는 개념이 도입되면서 Visa,Master사에서 우리 카드를 많이 사용하게 하려면 안전하게 사용할 수 있어야 된다고 생각해서 만든 암호화 프로토콜이 SET(Secure Electronic Protocol)입니다.

굉장히 잘 만들어진 프로토콜이며, 인터넷이 보편화 되지 않았을 당시에는 무거워서 사용이 주춤했었다가 오늘날 개선을 거쳐 PG를 기반으로 한 온라인 거래가 만들어 지게 되었고, 신용카드 거래 뿐만 아니라 다른 쪽으로도 충분히 응용될 가능성이 높아서 소개를 합니다.

지불 게이트웨이(PG)가 은행과 상점 사이에 있으면서 사용자의 지불 정보(이 사용자의  credit card가 맞다)와 판매자의 판매정보가 맞다는 인증을 은행에게 해주면 은행은 상점에게 지불을 하게 됩니다. 오늘날의 모델을 유사하게 따르고 있습니다.

SET 프로토콜이 중요하게 생각하는 것

● 온라인으로 이루어지는 구매정보와 신용카드정보와 같은 정보의 기밀성

● 중간에 위변조가 되면 그 사실을 알 수 있어야 한다(무결성을 제공)

● 사용자 인증(사용자의 계좌정보가 유효한 계좌정보이다)

● 판매자 인증(판매자의 은행 계좌 정보도 유효하다)

 

SET이 제공하는 것

● Privacy 문제도 고려 ☞ 요소간의 필요로 하는 정보가 다르다 ☞ 이를 감추면서 인증을 어떻게 할 것인가?

    사용자가 온라인 쇼핑몰에 나의 신용카드 정보를 등록->판매자가 나의 정보를 수집하는게 싫다

    사용자의 상점 사이에서는 주문정보만 있으면 됩니다.(상점은 사용자의 지불정보에 대해서는 알 필요가 없다)

    지불 게이트 웨이는 사용자의 신용카드가 유효한지 알아야 하지만 사용자의 구매정보를 알 필요는 없습니다.

    사용자와 은행 사이에서는 지불정보만 있으면 됩니다.

 

이중 서명(이중해시)

사용자는 온라인 스토어에서 사면서 구매정보가 있고, 어떤 카드로 사며 그 카드의 정보와 같은 지불정보가 있습니다.

먼저 서로 분리를 완벽하게 합니다.

각각의 해시값을 먼저 만들고, 서로 별도의 두 해시값을 concatenate시킵니다.

(160 bit + 160 bit) = 320 bit 짜리 해시값이 만들어 집니다. ->다시 해시 시킵니다.

사용자는 결과적으로 이 이중해시한 이 값으로 서명 생성을 합니다.

 

PG가 개별적으로 소프트웨어가 돌아가서 실행되었던 것이 아니라 상점을 통해서 PG에게 정보가 넘어가는 방법이었기 때문에 사용자가 모든 정보를 상점에게 준 다음에 상점이 지불정보를 PG에게 재전송을 합니다.

그러다보니, 지불정보와 구매정보를 모두 상점에게 주게 되면, 상점이 구매정보도 알고 지불정보도 알게 되서 문제가 발생

 

따라서 사용자가 상점에게 정보를 줄때, 구매정보는 그냥 줍니다. 하지만 지불정보는 그냥 줄 수 없으므로 암호화를 시켜서 전달을 해야 합니다. 그럼 암호화를 시킬 때, 무엇으로 암호화를 시켜야 PG만 열어 볼 수 있을까?

☞ PG의 공개키로 암호화를 시키면 됩니다.

 

암호화를 공개키를 사용을 하면, 속도가 너무 느리게 되므로 전자봉투(하이브리드 암호화)를 사용하게 됩니다.

대칭키(랜덤하게 생성한 비밀키)를 이용해서 지불정보를 암호화 합니다. 이 랜덤 비밀키는 PG만 알아야 하기 때문에

Public_Encryption을 하는데 PG의 공개키로 랜덤 비밀키를 암호화를 합니다.

 

● 지불정보는 대칭키(비밀키)로 암호화

● 대칭키(비밀키)는 PG의 공개키로 암호화

 

☞ 결과적으로 사용자가 생성한 구매정보 + 암호화한 지불정보 + 암호화한 키정보 + 구매정보,지불정보의 해시값 + 구매정보 해시값을 사용자의 개인키로 암호화한 사용자의 서명정보  총 5가지를 상점에게 보냅니다.

 

☞ 상점은 사용자가 구매한 구매정보와 상점이 판 판매정보가 맞는지만 확인합니다.  판매자가 직접 작성한(실제로 사용자에게 판) 구매정보를 해시해서 사용자가 보내온 구매정보의 해시값을 빼버리고 보내온 지불정보의 해시값(지불정보에 대한 것은 믿는다)과 합친 후 해시해서 사용자의 공개키를 사용해서 사용자가 보내준 해시값을 복호화 한 후에 같은지 비교합니다.

 

☞ PG는 구매정보는 관심 없습니다. 상점에게 받은 데이터를 자신의 개인키로 복호화하여서 대칭키를 알아냅니다. 대칭키로 지불정보의 원문을 알아내어야 합니다. 원문을 조회해서 사용가능한 카드인지 확인 후 사용가능하면 이것에 대한 서명검증을 합니다. 즉 사용자가 이 지불정보를 생성한 것이 맞다는 것을 검증하는겁니다. 승인된 지불정보를 다시 해시하고 구매정보의 해시값과 합쳐서 이중해시를 합니다. 사용자의 공개키를 사용해서 사용자가 보내준 해시값을 복호화 한 후에 같은지 비교합니다. 맞으면 은행에게 상점으로부터 대금을 보내라고 할 수 있습니다.

 

1995년도에 SET이 더 발전되어서 Cyber Cash가 등장하게 됩니다. 이는 현재 국내의 상당수 신용카드 결제 시스템과 비슷하게 동작합니다.  Cyber Cash가 PG의 역할을 해주게 되는것입니다.  판매자에게 주문 내역 및 결제 정보를 암호화해서 전달하고 판매자 또한 결제 정보를 확인 후, 전자 서명을 하여서 Cyber Cash서버에 전송하게 됩니다. SET처럼 판매자는 고객의 지불정보를 볼 수 없습니다. 하지만 SET과의 다른점은 Cyber Cash 서버는 고객의 구매 내역 정보를 알게 되는 것입니다.

 

 

다음에는 전자 화폐에 대해서 자세히 공부해 보겠습니당~