KR100486169B1 - 전자계좌이체를 이용한 전자지불방법 및 그 장치 - Google Patents

Abstract

본 발명은 전자상거래 등에서 사용될 수 있는 대금지불에 관한 방법 및 그 장치에 관한 것으로 MAC 또는 해쉬함수를 이용한 SSL기반의 전자계좌이체에 의한 전자지불방법 및 그 시스템에 관한 것이다.

본 발명에 의한 전자계좌이체방법은 거래에 필요한 기초정보를 은행에 등록하고 얻고, 지불자 컴퓨터에서 거래정보를 얻고, 수불자 컴퓨터에서 앞의 거래정보의 이상유무를 점검하고, 은행 컴퓨터에서 지불을 승인할 것인지 여부를 판단하여 지불자의 계좌에서 수불자의 계좌로 자금을 이체하며, 이때 영수증값을 발생시켜 이를 지불자 컴퓨터에 전송함으로써 지불자는 계좌이체가 성공적으로 이루어졌는지 여부를 확인할 수 있게하는데 특징이 있다. 특히 이 과정에서 MAC 또는 해쉬함수를 이용하여 각종 정보를 암호화함으로써 불필요한 정보의 노출 및 데이터가 조작되는 것을 예방할 수 있으며, 또한 기존 프로토콜에 비해 추가적인 연산량과 데이터 저장량 등이 적어서 시스템 구축비용이 적게 드는 특징이 있다.

Description

전자계좌이체를 이용한 전자지불방법 및 그 장치{The electronic payment method using a secure electronic funds transfer and thereof apparatus}

본 발명은 전자상거래 등에서 사용될 수 있는 대금지불에 관한 방법 및 그 장치에 관한 것으로 SSL을 이용한 전자계좌이체에 의한 전자지불방법 및 그 시스템에 관한 것이다.

인터넷을 이용한 전자상거래의 눈부신 발전은 소비자와 기업들로 하여금 편리한 상거래 환경을 제공하고 있다. 그러나 이러한 전자상거래는 시간과 공간의 제약을 줄인다는 장점이 있지만 그 이면에는 개인정보나 기업기밀의 누출에 대한 위험성이 심각한 문제점으로 인식되고 있다. 이러한 위험성이 존재하는 대부분은 대금을 지불하는 과정에서 주로 발생하며, 이와 같은 위험으로부터 개인과 기업의 중요한 정보를 보호하기 위해 전자지불 시스템에 대한 연구가 활발히 이루어지고 있으며 N.Asokan 등의 전자지불시스템의 분류에 따르면 SET이나 iKP 등의 신용카드 혹은 후지불방식(check-like systems), e-cash나 Mondex 등의 전자현금시스템(cash-like payment systems), NetBill이나 Millicent, μ-iKP 등의 소액지불 시스템(micro payments) 등으로 나눌 수 있다. 대부분의 쇼핑몰들은 고객의 신용정보를 보호하기 위해 SSL을 사용하고 있다. 고객의 신용정보와 지불 정보는 SSL을 통하여 쇼핑몰로 전달되고, 쇼핑몰은 그 정보를 신용기관인 매입사로 보내어 승인을 받은 후, 상품을 전달한다.

이러한 지불 프로토콜의 형태를 도 4로 도식화하였으며, 표 3에 표기법을 설명하였다. 고객은 공개키 인증서를 사용하지 않으며, 상점과 신용기관은 X.509형식의 공개키 인증서를 사용한다.

표 기	의 미
SEC={CARD, VAL}PIOIAPPNACK	신용카드의 번호, 유효기간지불 금액 등의 지불 정보상품 수령인등의 주문 정보신용기관의 지불승인번호상점의 거래승인신호

고객은 인터넷 상점에서 상품을 선택하고, 홈페이지상의 지불 버튼을 눌러 지불의사를 밝히면, 다음과 같은 단계를 거쳐 지불 프로토콜이 수행된다. 단, SSL(1)과 (2)는 지불 프로토콜이 시작되기 전에 설정되고, 지불 프로토콜이 종료된 후 닫힌다.

① 고객은 SEC, PI, OI를 상점에게 전송한다.

② 상점은 SEC와 PI를 신용기관에게 전송한다.

③ 신용기관은 SEC를 검증하여 지불을 승인하고, 지불승인번호를 상점에게 전송한다.

④ 상점은 고객에게 거래승인신호를 전송하고, 상품 배달을 시작한다. 고객은 거래승인신호를 받고 프로토콜을 종료한다.

이러한 프로토콜에 대한 공격을 살펴보면, 고객과 신용기관은 고객의 신용정보를 불법으로 사용하지 않는다고 생각할 수 있으므로, 프로토콜에 대한 공격은 상점 내부자에 의한 공격과 상점 외부자에 의한 공격으로 나누어 볼 수 있다. 상점 내부자에 의한 공격은 SSL은 서버와 클라이언트간의 통신경로에 대해서만 보안 서비스를 제공하므로, 고객의 신용정보는 상점에게 그대로 노출됨에 따라서 악의를 가진 상점 내부자는 표 4와 같은 공격이 가능하다. 한편, 상점 외부자에 의한 공격은 SSL-128bit를 해독하여야 가능하다. 현재의 해독 기술로는 SSL-128bit를 해독하는 것은 불가능하지만, 만약 가능하다고 가정하였을 경우 표 5와 같은 공격이 가능하다.

공격 유형	공격 내용
고객의 비밀정보 SEC의 유출	제3자에게 고객의 비밀정보를 유출시켜, 고객에게 피해를 입힐 수 있다.
메시지의 재사용	고객이 한번 주문한 내용을 여러번 사용하여, 고객이 여러번 주문하였다고 주장할 수 있다.
지불정보PI의 조작	주문가격을 조작하여, 고객에게 높은 가격을 받을 수 있다.
주문정보OI의 조작	주문 내용을 조작하여, 고객이 주문한 상품과 다른 상품을 전달할 수 있다.
허위 승인	신용기관으로부터 지불승인을 받지 않고 고객에게 지불승인을 받았다고 속일 수 있다.
허위 취소	주문 정보를 받은 후 고객에게 에러신호를 전송하고 신용기관과 거래를 계속할 수 있다.

공격 유형	공격 내용
다른 고객에의한 도용	고객의 비밀정보를 도용하여 합법적인 고객으로 위장할 수 있다.
다른 합법적인상점에서 도용	고객의 비밀정보를 도용하여 신용기관으로부터 허위 거래에 대한 승인을 받을 수 있다.

이상에서 살펴본 바와 같이 SSL을 전자지불시스템으로 그대로 사용할 경우 고객의 비밀정보가 상점에게 유출될 수 있는 위험성이 존재하는 문제점이 있다.

본 발명이 이루고자하는 기술적 과제는 SSL을 이용한 기존의 시스템에 부가적인 암호프로토콜을 추가하여 고객의 정보가 유출되지 않는 전자계좌이체방법 및 그 시스템을 제공하는데 있다.

본 발명이 이루고자하는 다른 기술적 과제는 소액지불에도 적합하도록 MAC(message authentication code)와 해쉬함수 만을 지불과정에서 사용함으로써 저렴한 처리비용으로 운용할 수 있는 전자계좌이체방법 및 그 시스템을 제공하는데 있다.

상기 과제를 해결하기 위한 본 발명의 전자계좌이체방법은 (a) 은행 컴퓨터에서 지불자비밀키(PSWD), 지불자계좌코드(ACC_NUM)와 지불자계좌비밀코드(ACC_PSWD)로 구성되는 지불자비밀정보(SEC)를 포함하는 정보를 등록받는 단계; (b) 지불자 컴퓨터에서 상기 지불자비밀키(PSWD)를 킷값으로 하고 상기 지불자비밀정보(SEC), 지불정보(PI), 주문정보(OI)를 포함하는 정보를 입력값으로 하여 암호화한 지불승인정보(PAI)를 생성하는 단계; (c) 지불자 컴퓨터에서 상기 지불자비밀정보(SEC), 상기 지불정보(PI), 상기 주문정보(OI), 상기 지불승인정보(PAI)를 포함하는 정보를 수불자 컴퓨터로 전송하는 단계; (d) 수불자 컴퓨터에서 상기 주문정보(OI)에 따라 지불정보(PI)가 정당한지 여부를 검사하는 단계; (e) 수불자 컴퓨터에서 상기 지불자비밀정보(SEC), 상기 지불정보(PI), 상기 주문정보(OI), 상기 지불승인정보(PAI)를 포함하는 정보를 은행 컴퓨터로 전송하는 단계; (f) 은행 컴퓨터에서 상기 등록된 지불자비밀키값(PSWD)을 킷값으로 하고 상기 전송받은 상기 지불자비밀정보(SEC), 상기 지불정보(PI), 상기 주문정보(OI)를를 포함하는 정보를 입력값으로 하여 암호화하여 계산한 지불승인검사정보(CH_PAI)값을 구하여 상기 전송받은 지불승인정보(PAI)에 이상이 없는지를 검사하는 단계; 및 (g) 은행 컴퓨터에서 상기 (f)단계에서 지불승인정보(PAI)에 이상이 없으면 상기 지불정보(PI)에 따라 지불자 계좌에서 수불자 계좌로 자금을 이체하는 단계를 포함하는 것을 특징으로 하며, 상기 (c)단계는 지불자 컴퓨터에서 상기 지불자비밀정보(SEC), 수불자 컴퓨터로 전송하는데 있어서 수불자에게 지불자비밀정보(SEC)가 노출되지 않도록 지불자비밀정보(SEC)값을 포함하는 정보를 입력값으로 하여 역변환이 불가능하도록 암호화하여 얻은 비밀정보암호화값(CSEC)을 상기 지불자비밀정보(SEC)에 대신하여 수불자 컴퓨터에 전송하는 것을 특징으로 한다. 또한 상기 (e)단계는 수불자 컴퓨터에서 상기 주문정보(OI)를 은행 컴퓨터로 전송하는데 있어서 은행에 주문정보(OI)가 노출되지 않도록 주문정보(OI)를 입력값으로 하여 역변환이 불가능하도록 암호화하여 얻은 주문정보암호값(COI)을 주문정보(OI)를 대신하여 은행 컴퓨터에 전송하는 것을 특징으로 한다. 그리고 상기 (g)단계는 (ga)상기 지불자 계좌에서 수불자 계좌로 자금을 이체한 후에는 지불승인코드(APPN)을 발생시키고 상기 지불정보(PI), 상기 주문정보(OI) 또는 주문정보암호화값(COI), 상기 은행 컴퓨터에 등록된 지불자비밀정보(SEC)를 포함하는 정보를 입력값으로 하여 역변환이 불가능하도록 암호화한 값과 상기 지불승인코드(APPN)을 입력으로 하여 역변환이 불가능하도록 암호화한 영수증값(HT)를 구하고, 상기 지불승인코드(APPN) 및 상기 영수증값(HT)를 수불자컴퓨터에 전송하는 단계; (gb) 수불자 컴퓨터는 전송받은 상기 지불승인코드(APPN) 및 상기 영수증값(HT)을 지불자 컴퓨터에 전송하는 단계; 및 (gc) 지불자 컴퓨터는 상기 지불정보(PI), 상기 주문정보(OI) 또는 상기 주문정보(OI)를 암호화값(COI), 상기 지불자비밀정보(SEC)를 포함하는 정보를 입력값으로 하여 역변환이 불가능하도록 암호화한 값과 전송받은 상기 지불승인코드(APPN)을 입력으로 하여 역변환이 불가능하도록 암호화한 영수증값검사정보(CH_HT)를 구하고, 상기 전송받은 영수증값(HT)와 비교하여 이상이 없는지를 검사하여 지불결과를 지불자에게 제공하는 단계를 더 포함할 수 있는 것을 특징으로 한다.

한편, 상기 전자계좌이체 방법은 (a1) 상기 (d)단계에서 상기 주문정보(OI)에 따라 지불정보(PI)가 정당한지 여부를 검사하여 이상이 있는 경우에는 에러정보를 생성하고, 수불자의 비밀키를 이용하여 서명한 값을 상기 지불자 컴퓨터에 전송하는 단계; (a2) 상기 (f)단계에서 상기 지불승인정보(PAI)에 에러가 있는 경우에는 그에 대응하는 에러정보를 생성하여 수불자 컴퓨터로 전송하고, 상기 수불자 컴퓨터는 상기 에러정보를 지불자 컴퓨터로 전송하는 단계; (a3) 상기 (g)단계에서 상기 자금이체에 에러가 있는 경우에는 그에 상응하는 에러정보를 생성하여 수불자 컴퓨터로 전송하고, 상기 수불자 컴퓨터는 상기 에러정보를 지불자 컴퓨터로 전송하는 단계; 및 (a4) 상기 (a1),(a2) 및 (a3)단계에서 상기 에러정보를 수신한 지불자 컴퓨터는 에러정보 및 지불자가 지불을 거부하거나 취소하는데 근거가 되는 에러정보를 수신할 당시의 거래관련정보를 지불자에게 제공하는 단계를 더 포함할 수 있다.

상기 과제를 해결하기 위한 본 발명의 전자계좌이체에 의한 지불방법은 (a) 은행에 등록된 지불자비밀키(PSWD) 및 계좌코드(ACC_NUM)와 계좌비밀코드(ACC_PSWD)로 구성되는 지불자비밀정보(SEC), 지불금액등의 지불정보(PI), 구매상품등의 주문정보(OI)를 포함하는 정보를 얻는 단계; (b) 지불자 컴퓨터에서 상기 지불자비밀키(PSWD)를 킷값으로 하고 상기 지불자비밀정보(SEC), 상기 지불정보(PI), 상기 주문정보(OI)를 포함하는 정보를 입력값으로 하여 암호화한 지불승인정보(PAI)를 생성하는 단계; (c) 상기 지불자비밀정보(SEC), 지불금액등의 지불정보(PI), 구매상품등의 주문정보(OI)를 포함하는 정보를 수불자 컴퓨터로 전송하는 단계; (d) 은행 컴퓨터에서 계산된 대금지불에 대한 영수증값(HT) 및 지불승인코드(APPN)을 전송받는 단계; 및 (e) 지불자 컴퓨터는 상기 (a)단계에서 얻은 상기 지불정보(PI), 상기 주문정보(OI) 또는 상기 주문정보(OI)를 암호화값(COI), 상기 지불자비밀정보(SEC)를 포함하는 정보를 입력값으로 하여 암호화한 값과 전송받은 상기 지불승인코드(APPN)을 입력으로 하여 암호화한 영수증값검사정보(CH_HT)를 구하고, 상기 전송받은 영수증값(HT)와 비교하여 이상이 없는지를 검사하여 지불결과를 지불자에게 제공하는 단계를 포함하는 것을 특징으로 하고, 상기 (b)단계의 지불승인판단정보(PAI)는 상기 (a)단계에서 지불자아이디(ID), 지불자의 고유코드(CID), 수불자의 고유코드(MID), 은행의 고유코드(TID)로 구성되는 고유코드정보(IDS), 거래코드(MSEQ), 거래시간을 정수로 나타낸 거래시간정수(TS)에 관한 정보를 추가로 얻고, 상기 지불자아이디(ID), 지불자의 고유코드(CID), 수불자의 고유코드(MID), 은행의 고유코드(TID)로 구성되는 고유코드정보(IDS), 거래코드(MSEQ), 지불정보(PI), 주문정보(OI)의 해쉬값, 상기 지불자의 계좌코드(ACC_NUM) 및 계좌비밀코드(ACC_PSWD)로 구성되는 지불자비밀정보(SEC)와 거래시간을 정수로 나타낸 거래시간정수(TS)의 해쉬값 및 상기 거래시간정수(TS)를 입력으로 하고 지불자비밀키(PSWD)를 키값으로한 해쉬함수의 값을 구함으로써 지불승인판단정보(PAI)를 계산하는 것을 특징으로 한다. 또한 상기 (c)단계이후 (d)단계이전에 수불자 컴퓨터로부터 에러정보를 수신한 경우에는 상기 에러정보 및 지불자가 지불을 거부하거나 취소하는데 근거가 되는 에러정보를 수신할 당시의 거래관련정보를 지불자에게 제공하는 단계를 더 포함할 수 있다.

상기 과제를 해결하기 위한 본 발명의 전자계좌이체에 의한 수불방법은 (a) 지불자비밀정보(SEC), 지불금액등의 지불정보(PI), 구매상품등의 주문정보(OI)를 포함하는 정보를 지불자 컴퓨터로부터 수신하는 단계; (b) 상기 (a)단계에서 전송받은 지불정보(PI)와 주문정보(OI)를 점검하여 이상이 없으면 상기 전송받은 정보를 은행 컴퓨터에 전송하는 단계; (c) 은행컴퓨터로부터 지불승인코드(APPN) 및 대금지불에 대한 영수증값(HT)을 전송 받아 이를 지불자 컴퓨터에 전송하는 단계를 포함하는 것을 특징으로 하며, 상기 (b)단계는 수불자 컴퓨터에서 상기 주문정보(OI)를 은행 컴퓨터로 전송하는데 있어서 은행에 주문정보(OI)가 노출되지 않도록 주문정보(OI)를 입력값으로 하여 역변환이 불가능하도록 암호화하여 얻은 주문정보암호값(COI)를 주문정보(OI)를 대신하여 은행 컴퓨터에 전송하는 것을 특징으로 하고, 상기 지불정보(PI)와 상기 주문정보(OI)의 내용에 이상이 있는 경우, 주문에러정보(ERR_OI)를 생성하고 상기 주문에러정보(ERR_OI)를 포함하는 정보를 수불자의 비밀키를 이용하여 디지틀 서명하여 변환한 값을 지불자 컴퓨터로 전송하는 단계인 것을 특징으로 한다. 또한 상기 (b)단계이후 상기 (c)단계이전에 은행 컴퓨터로부터 지불승인에러정보(ERR_PAI) 및 상기 지불정보(PI), 상기 주문정보(OI) 또는 주문정보암호화값(COI), 상기 은행 컴퓨터에 등록된 지불자비밀정보(SEC)를 포함하는 정보를 입력값으로 하여 역변환이 불가능하도록 암호화한 값과 지불승인에러정보(ERR_PAI)를 입력으로 하는 해쉬함수값을 전송받은 경우에, 이 정보를 지불자 컴퓨터로 전송하는 단계를 더 포함하는 것을 특징으로 한다.

상기 과제를 해결하기 위한 본 발명의 전자계좌이체에 대한 지불승인방법은 (a) 지불자비밀키(PSWD) 및 계좌코드(ACC_NUM)와 계좌비밀코드(ACC_PSWD)로 구성되는 지불자비밀정보(SEC)를 포함하는 정보를 등록받는 단계; (b) 지불자비밀정보(SEC), 지불금액등의 지불정보(PI), 구매상품등의 주문정보(OI)를 포함하는 정보를 수불자 컴퓨터로부터 수신하는 단계; (c) 상기 등록된 지불자비밀키값(PSWD)을 킷값으로 하고 상기 전송받은 상기 지불자비밀정보(SEC), 상기 지불정보(PI), 상기 주문정보(OI)를 포함하는 정보를 입력값으로 하여 암호화하여 계산한 지불승인검사정보(CH_PAI)값을 구하여 상기 전송받은 지불승인정보(PAI)에 이상이 없는지를 검사하는 단계; 및 (d) 은행 컴퓨터에서 상기 (c)단계에서 지불승인정보(PAI)에 이상이 없으면 상기 지불정보(PI)에 따라 지불자 계좌에서 수불자 계좌로 자금을 이체하는 단계를 포함하는 것을 특징으로 하며, 상기 (c)단계의 지불승인정보(PAI)의 검사는 상기 (b)단계에서 거래시간을 정수로 표현한 거래시간정수(TS)를 더 전송받고, 지난번 거래시의 최후거래시간정수(L_TS)와 현재의 거래시간정수(TS)를 비교하여 상기 거래시간정수(TS)가 최후거래시간정수(L_TS)보다 작거나 같은 경우에는 지불을 승인하지 않는 것을 특징으로 한다. 또한 상기 (d)단계는 지불자 계좌에서 수불자 계좌로 자금을 이체한 후에는 지불승인코드(APPN)을 발생시키고 상기 지불정보(PI), 상기 주문정보(OI) 또는 주문정보암호화값(COI), 상기 은행 컴퓨터에 등록된 지불자비밀정보(SEC)를 포함하는 정보를 입력값으로 하여 역변환이 불가능하도록 암호화한 값과 상기 지불승인코드(APPN)을 입력으로 하여 역변환이 불가능하도록 암호화한 영수증값(HT)를 구하고, 상기 지불승인코드(APPN) 및 상기 영수증값(HT)를 수불자컴퓨터에 전송하는 단계를 더 포함하는 것을 특징으로 하고, 상기 영수증값(HT)는 상기 지불자아이디(ID), 지불자의 고유코드(CID), 수불자의 고유코드(MID), 은행의 고유코드(TID)로 구성되는 고유코드정보(IDS), 거래코드(MSEQ), 거래시간정수(TS)를 수불자 컴퓨터로부터 더 전송받고, 상기 전송받은 지불자아이디(ID), 고유코드정보(IDS), 수불자의 거래코드(MSEQ), 지불정보(PI), 주문정보(OI)의 해쉬값, 지불자의 계좌코드(ACC_NUM) 및 계좌비밀코드(ACC_PSWD)로 구성되는 지불자비밀정보(SEC), 거래시간정수(TS)를 입력으로 한 해쉬함수값과 상기 지불승인코드(APPN)을 입력으로 한 해쉬함수값을 구함으로써 대금지불에 대한 영수증값(HT)를 구하는 것을 특징으로 한다. 또한 상기 (c)단계는 상기 지불승인검사정보(CH_PAI)값과 상기 지불승인정보(PAI)값이 동일하지 않은 경우에, 지불승인에러정보(ERR_PAI) 및 상기 지불정보(PI), 상기 주문정보(OI) 또는 주문정보암호화값(COI), 상기 은행 컴퓨터에 등록된 지불자비밀정보(SEC)를 포함하는 정보를 입력값으로 하여 역변환이 불가능하도록 암호화한 값과 지불승인에러정보(ERR_PAI)를 입력으로 하는 해쉬함수값 및 상기 지불승인에러정보(ERR_PAI)를 수불자 컴퓨터에 전송하는 단계인 것을 특징으로 하고 있다. 한편 상기 (d)단계는 상기 지불자의 계좌에서 상기 수불자 계좌로 상기 지불정보(PI)에 해당하는 금액을 이체하는데 있어서 에러가 발생한 경우에, 작업을 취소하고 이체에러정보를 수불자 컴퓨터로 전송하는 것을 특징으로 하고 있다.

상기 과제를 해결하기 위한 본 발명의 전자계좌이체에 의한 전자지불 시스템은 거래에 필요한 정보를 송신 또는 수신하는 송수신부; 상기 송수신부에서 수신받은 정보를 표시하고 거래에 필요한 정보를 입력받는 입출력부; 상기 입출력부로부터 입력받은 정보를 사용하여 거래에 필요한 연산을 수행하는 연산부; 거래가 정상종료되었는지 여부를 판단하는 판단부를 포함하는 지불자 컴퓨터;

거래에 필요한 정보를 연산하는 연산부; 지불자 컴퓨터에 거래에 필요한 정보를 전송받고, 은행 컴퓨터에 상기 거래에 필요한 정보를 전송하는 송수신부; 거래의 내용이 맞는지 여부를 점검하는 판단부를 포함하는 하는 수불자 컴퓨터;

거래에 필요한 정보를 송신 또는 수신하는 송수신부; 지불승인 여부를 판단하는 판단부; 지불자계좌에서 수불자계좌로 지불정보(PI)에 해당하는 금액을 이체시키는 계좌이체부; 대금지불에 대한 영수증값(HT)을 계산하는 연산부를 포함하는 은행 컴퓨터로 구성되는 것을 특징으로 한다.

본 발명에서 전자계좌이체를 하기 위해 지불자 컴퓨터, 수불자 컴퓨터 및 은행 컴퓨터가 수행하는 각 단계의 작업들 전체를 지칭하여 전자계좌이체 프로토콜이라고 할때, 본 발명에서 제안하는 전자계좌이체 프로토콜은 SSL을 기반으로 하고 있는바, 이하에서 SSL에 대하여 설명한다. SSL(secure socket layer)은 전자지불방법 및 그 시스템이 아니라 단지 종단간 사용자사이의 안전한 채널을 보장해주는 프로토콜이지만 SSL이 간단히 구현될 수 있고 운영의 비용 면에서 유리하기 때문에 SSL을 사용하는 지불시스템이 보편화되고 있다. SSL은 서버와 클라이언트 사이의 통신과정에서 인증(authentication), 기밀성(confidentiality), 무결성(integrity) 서비스를 제공하여 도청(eavesdropping), 조작(tampering), 메시지 위조(message forgery)를 막도록 설계되었다. 현재 버전 3.0이 많이 사용되고 있으며, 이를 토대로 IETF(internet engineering task force)에서 표준화한 TLS(transport layer security)도 사용되고있다. 이전까지는 40-bit의 SSL만이 미국 외의 국가에서 허용되었지만, 현재는 브라우저의 간단한 패치만으로 128-bit SSL의 사용이 가능하다. 물론 서버 측에서도 128-bit의 SSL을 지원해야 한다. SSL은 도 1과 같이 두 개의 계층, 네 개의 프로토콜로 이루어져 있다. Handshake protocol, change cipher spec protocol, alert protocol은 SSL 동작에 대한 관리를 위해 사용되며, record protocol은 전송되는 메시지에 대해 기밀성과 무결성을 제공한다. Handshake protocol은 서버와 클라이언트 사이의 인증, 세션 정보와 연결 정보 생성 등을 수행한다. Change cipher spec protocol은 설정된 세션 정보와 연결 정보를 적용한다는 것을 상대측에게 알린다. Alert protocol은 오류 메시지를 전송한다.

서버와 클라이언트가 연결할 때마다 세션 정보와 연결 정보를 생성하는 것은 비효율적이므로, SSL은 여러 번의 연결을 하나의 세션으로 묶을 수 있다. 즉, 한번 생성된 세션 정보를 여러 번 사용하고, 연결 정보는 매번 새롭게 생성한다. 세션 정보는 표 1과 같고, 연결 정보는 표 2와 같다.

session identifier	서버가 생성하는 임의의 바이트
peer certificate	서버와 클라이언트의 X.509 인증서 (옵션)
compression method	암호화 이전에 사용할 압축 알고리즘
cihper spec	사용할 암호 알고리즘
master secret	서버와 클라이언트가 공유하는 비밀정보
is resumable	세션정보의 재사용 여부를 나타내는 플래그

server and client random	서버와 클라이언트가 생성하는 임의의 수
server write MAC secret	서버가 전송하는 데이터의 MAC용 비밀키
client write MAC secret	클라이언트가 전송하는 데이터의 MAC용 비밀키
server write key	서버가 전송하는 데이터의 암복호용 비밀키
client write key	클라이언트가 전송하는 데이터 암복호용 비밀키
initialization vectors	블록암호에서 사용되는 IV값들
sequence numbers	송수신되는 각 메시지에 대한 순서번호

Handshake protocol은 서버와 클라이언트 사이에 인증을 하고, 한 세션 동안 사용되는 암호 스펙을 생성하는 프로토콜이다. SSL 서버와 클라이언트가 데이터를 주고받기 전에 수행되며, 프로토콜 버전 확인, 암호 알고리즘 선택, 선택적인 인증, 공개키암호를 이용한 비밀정보 공유 등이 이루어진다. 도 2와 같이 서버와 클라이언트간 서로 사용할 암호방법을 합의하는 부분, 서버 인증과 키 교환 부분, 클라이언트 인증과 키 교환 부분, 종료 부분으로 나눌 수 있다.

프로토콜 수행 중에 주고받는 메시지는 hello request, client hello, server hello, certificate, server key exchange, certificate request, client key exchange, certificate verify, change cipher spec, finished 등이 있다.

여기서 Hello request는 서버가 언제든지 클라이언트에게 보낼 수 있으며, 클라이언트에게 새로운 암호 스펙 설정을 해야한다는 것을 알리는 역할을 한다.

클라이언트는 client hello 메시지를 통해 클라이언트의 SSL 버전, 클라이언트에서 생성한 임의의 수, 세션 ID, 클라이언트가 지원하는 cipher suite 리스트, 클라이언트가 지원하는 압축방법 리스트 등의 정보를 서버에게 전송한다. 여기서 cipher suite는 "SSL_(키 교환 알고리즘)_WITH_(암호 알고리즘)_(해쉬 알고리즘)"과 같은 형식으로 표현되며, 아래에 몇 가지 예를 들었다.

▷ SSL_NULL_WITH_NULL_NULL : 아무런 암호 알고리즘을 사용하지 않는다.

▷ SSL_RSA_WITH_DES_CBC_SHA : 키 교환 알고리즘으로는 RSA, 암호 알고리즘으로는 CBC 모드의 DES 해쉬 알고리즘으로는 SHA를 사용한다.

▷ SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 : 키 교환 알고리즘으로는 anonymous Diffie-Hellman, 암호 알고리즘으로는 40-bit RC4, 해쉬 알고리즘으로는 MD5로 예전의 수출 가능한 cipher suite이다.

서버는 Server hello를 통해 서버의 SSL버전, 서버에서 생성한 임의의 수, 세션 ID, 클라이언트가 보낸 cipher suite 리스트 중에서 선택한 하나의 cipher suite, 클라이언트가 보낸 압축방법 리스트에서 선택한 압축방법 등의 정보를 클라이언트에 보낸다. 서버와 클라이언트가 동의하여 선택할 수 있는 키 교환 알고리즘과 그 사용방법은 다음과 같다.

▷ RSA : pre_master_secret를 수신자의 RSA 공개키로 암호화한다. 사용되는 RSA 공개키에 대한 인증서를 사용한다.

▷ Fixed Diffie-Hellman : Diffie-Hellman key exchange를 이용하여 pre_master_secret을 생성한다. Diffie-Hellman 공개 값에 대한 인증서를 사용한다.

▷ Ephemeral Diffie-Hellman : Diffie-Hellman key exchange를 이용하여 pre_master_secret을 생성한다. Diffie-Hellman 공개 값을 임시로 생성하여, RSA 서명이나 DSS서명을 한 후, 서명 확인키에 대한 인증서를 함께 사용한다. 가장 안전한 키 교환 알고리즘이다.

▷ Anonymous Diffie-Hellman : Diffie-Hellman key exchange를 이용하여 pre_master_secret을 생성한다. Diffie-Hellman 공개 값을 임시로 생성하여 사용한다. 공개키 인증서를 사용하지 않는다. Man-in-the-middle 공격에 취약하여 사용시 주의가 요구된다.

Server certificate단계에 있어서 일반적으로 공개키 인증서는 X.509v3 인증서를 사용하여, 앞 단계에서 합의한 키 교환 알고리즘에 따라 다음과 같이 사용된다.

▷ RSA : 서버는 암호용 RSA 공개키 인증서 또는 서명확인용 RSA 공개키 인증서를 전송한다.

▷ Fixed Diffie-Hellman : 서버는 Diffie-Hellman 공개 값 인증서를 전송한다.

▷ Ephemeral Diffie-Hellman : 서버는 서명확인용 RSA 또는 DSS 공개키 인증서를 전송한다.

▷ Anonymous Diffie-Hellman : 서버는 인증서를 전송하지 않는다.

Server key exchange단계는 앞 단계까지 수행된 결과에 따라 다음과 같이 사용된다.

▷ RSA : 서버가 암호용 RSA 공개키 인증서를 보낸 경우, 서버는 server key exchange 메시지를 사용하지 않는다. 서버가 서명확인용 RSA 공개키 인증서를 보낸 경우, 서버는 임시 암호용 RSA 비밀키와 공개키를 생성한 후, 생성된 공개키를 서명하여 전송한다.

▷ Fixed Diffie-Hellman : 공개키 인증서에 Diffie-Hellman 공개 값이 포함되어 있으므로, 서버는 server key exchange 메시지를 사용하지 않는다.

▷ Ephemeral Diffie-Hellman : 서버는 임시 Diffie-Hellman 공개 값을 생성한 후, RSA 서명이나 DSS 서명을 하여 전송한다.

▷ Anonymous Diffie-Hellman : 서버는 임시 Diffie-Hellman 공개 값을 생성하여 전송한다.

Certificate request단계에서는 서버가 non-anonymous일 경우, 클라이언트의 인증서를 요구하여 신뢰할 수 있는 클라이언트인지 확인할 수 있다.

Server hello done단계에서는 서버는 이 메시지를 보냄으로써 필요한 certificate, server key exchange, certificate request 메시지의 전송이 완료되었음을 알린다.

Client certificate단계에서는 서버로부터 클라이언트의 인증서 요청이 있을 경우, 클라이언트의 공개키 인증서를 보낸다. 만약 인증서를 가지고 있지 않다면 no certificate alert 메시지를 보낸다.

Client key exchange 단계에서 서버와 클라이언트는 세션키를 생성하는 데 사용되는 임의의 비밀정보인 pre_master_secret을 생성한다.

▷ RSA : pre_master_secret을 생성하여 암호용 RSA 공개키로 암호화하여 전송한다.

▷ Fixed Diffie-Hellman : 공개키 인증서에 Diffie-Hellman 공개 값이 포함되어 있으므로, 클라이언트는 client key exchange 메시지를 사용하지 않는다.

▷ Ephemeral or Anonymous Diffie-Hellman : 서버는 임시 Diffie-Hellman 공개 값을 생성하여 전송한다.

Certificate verify단계는 서버의 요구에 의해 클라이언트가 서명확인용 인증서를 전송할 경우, 클라이언트는 앞 단계까지의 handshake 메시지들과 생성된 master_secret 대한 해쉬코드를 서명하여 전송한다.

CertificateVerify.signature.md5_hash

MD5(master_secret||pad2||

MD5(handshake_messages||master_secret||pad1));

CertificateVerify.signature.sha_hash

SHA(master_secret||pad2||

SHA(handshake_messages||master_secret||pad1));

Change cipher spec, finished 단계에서 클라이언트는 change cipher spec 메시지를 서버에게 보내어, 이후의 전송되는 메시지는 새로이 생성된 암호 스펙을 사용한다는 것을 서버에게 알린다. 그후 즉시 finished 메시지를 생성하여 서버에게 전송한다. 그리고, 서버 역시 클라이언트에게 change cipher spec과 finished 메시지를 보냄으로써, 서버와 클라이언트간에 키 설정과 인증이 완료되었음을 확인한다. Finished 메시지는 master_secret, 앞 단계까지의 handshake 메시지들, 송신자에 대한 해쉬코드이다. 여기서 송신자는 서버 또는 클라이언트이다.

MD5(master_secret||pad2||

MD5(handshake_messages||Sender||master_secret||pad1));

SHA(master_secret||pad2||

SHA(handshake_messages||Sender||master_secret||pad1));

SSL에서 사용될 비밀정보는 handshake protocol의 certificate verify 메시지나 finished 메시지를 전송하기에 앞서 생성된다. Master secret과 key block은 다음과 같은 과정을 통해 생성된다. 이 때, key block은 필요한 만큼 생성한다.

master_secret

= MD5(pre_master_secret||SHA('A'||pre_master_secret||

ClientHello.random||ServerHello.random))||

MD5(pre_master_secret||SHA('BB'||pre_master_secret||

ClientHello.random||ServerHello.random))||

MD5(pre_master_secret||SHA('CCC'||pre_master_secret||

ClientHello.random||ServerHello.random))

key_block

= MD5(master_secret||SHA('A'||master_secret||

ServerHello.random||ClientHello.random))||

MD5(master_secret||SHA('BB'||master_secret||

ClientHello.random||ServerHello.random))||

MD5(master_secret||SHA('CCC'||master_secret||

ClientHello.random||ServerHello.random))||…

생성된 key block을 정해진 비트 수만큼 순서대로 잘라서, client write MAC secret, server write MAC secret, client write key, server write key, client write IV, server write IV로 사용한다.

Change cipher spec protocol은 한 바이트의 메시지 전송으로 이루어지는 데, 이 후에 전송되는 메시지는 새로이 생성된 암호 스펙을 사용한다는 것을 수신 측에게 알린다. 이전의 세션을 재사용 하는 경우라면, change cipher spec 메시지는 hello 메시지 뒤에 바로 전송된다.

Alert protocol은 압축 및 암호 오류, MAC 오류, handshake protocol 실패, 인증서 오류 등에 대한 메시지를 전송한다.

Record protocol은 handshake protocol에서 생성된 암호 스펙을 이용하여 실제 기밀성과 메시지 무결성을 제공하는 프로토콜로서, 도 3과 같이 동작한다. 전송은, 먼저 상위 응용 계층으로부터 임의의 크기의 데이터를 전달받고, 다음으로 메시지를 SSL에서 처리할 수 있는 데이터 블록 크기만큼씩 단편화하고, 경우에 따라서는 압축을 한 후, MAC과 암호화를 계산하여, TCP 계층으로 전달하는 과정을 거친다. 수신은, 수신된 데이터를 복호화하고, MAC의 유효성을 조사한 후, 압축 해제를 하고, 단편화된 데이터 조각을 모아서, 응용 계층으로 전달하는 과정을 통해 이루어진다.

MAC용 암호 알고리즘은 MD5, SHA-1 등이 사용된다. 서버는 server write MAC secret를 사용하여 MAC를 생성하고 client write MAC secret을 사용하여 수신한 MAC를 검증한다. 마찬가지로 클라이언트는 client write MAC secret를 사용하여 MAC를 생성하고 server write MAC secret을 사용하여 수신한 MAC를 검증한다. 한편 MAC 생성 시 전송순서번호를 포함시켜서, 메시지 오류 또는 변경을 감지할 수 있게 한다. 암복호용 암호 알고리즘은 DES, IDEA, RC4 등이 사용된다. 비밀키는 MAC처럼 server write key와 client write key를 사용한다.

보안에 대한 분석을 해보면 SSL은 서버와 클라이언트 사이의 안전하지 않은 통신경로에서 인증, 기밀성, 무결성 서비스를 제공한다.

이하에서는 본 발명에서 제안하는 전자계좌이체 프로토콜을 설명한다. 본 발명에서 제안하는 프로토콜에는 고객(customer), 상점(merchant), 은행(trusty)의 세 개체가 참여하며, 은행은 절대적 신용을 갖춘 신용기관의 역할을 동시에 수행한다. 여기서는 본 발명의 전자계좌이체 프로토콜을 전자상거래에 적용한 경우를 예로 들어서 설명하고, 편의상 금전을 지불할 사람의 대표적인 예로써 고객을, 그리고 금전을 수불할 사람의 대표적인 예로써 상점을 들어 설명하기로 한다. 제안하는 프로토콜에 필요한 요구조건들은 다음과 같다.

1. 고객의 비밀정보(계좌번호, 계좌비밀번호)는 상점에게 노출되지 않아야 한다.

2. 고객은 상점과의 거래를 위해서 반드시 은행과의 등록과정을 사전에 거쳐야 한다.

3. 고객의 구매정보는 은행에게 노출되지 않도록 한다.

4. 소액에 적합하도록 SSL 자체의 과정이외의 추가적인 공개키암호 및 서명은 가급적 피하도록 한다.

5. 은행은 신용기관으로서 상점과 고객 모두 절대적으로 신뢰할 수 있다. 도 5는 고객과 은행과의 사전등록절차를 설명한다. 고객은 해당은행에 계좌를 가지고 있는 상태에서 자신의 개인정보를 온라인 상에서 등록하여 자신만의 고유한 아이디를 발급 받는다. 은행은 각 개인의 고유한 아이디, 그에 상응하는 패스워드와 계좌에 대한 정보들을 데이터베이스에 등록한다. 이 정보들은 나중에 상점과의 지불과정에서 쓰이게 된다. 여기서 PSWD는 140-bit이면 충분히 안전하다고 알려져 있다.

사전등록절차에서 중요한 것은 은행의 데이터베이스가 외부의 공격으로부터 안전해야 한다는 것이다. 많은 고객들의 정보가 은행의 데이터베이스에 저장되어있기 때문이다. 이와 관련하여 데이터베이스 정보보호에 대한 추가적인 기술이 필요하지만 이러한 기술은 본 발명과 직접적인 연관이 없는 부분이므로 본 명세서에서는 언급하지 않기로 한다.

본 명세서에서 사용되는 용어들을 정리하면 위의 표 6과 같다.

표 기

의 미

IDPSWDERR_OI, ERR_PAIH(x)Hy(x)ACC_NUMBER,ACC_PSWDCSECCID, MID, TIDPIOICOITSL_TSMSEQAPPNPAICH_PAIHSCH_HSHTCH_HTSy(x)

금융기관에 등록한 지불자의 아이디금융기관에 등록한 MAC용 비밀키값주문에러정보, 지불승인에러정보입력 x에 대한 해쉬값키 y와 입력 x에 대한 keyed hash 값계좌 번호와 계좌 비밀번호, 즉 지불자비밀정보(SEC)비밀정보를 암호화한 비밀정보암호화값고객, 상점, 은행의 ID 즉 고유코드정보(IDS)지불 금액 등의 지불정보구매 상품등의 주문정보주문정보를 암호화한 주문정보암호화값거래 시작 시각의 정수값최후거래시간을 정수로 나타낸 최후거래시간정수상점의 거래 일련번호신용기관의 지불승인번호MAC으로 계산한 지불승인판단정보PAI값을 검사하기 위한 지불승인겁사정보영수증값(HT)를 생성하는데 필요한 부영수증값(HS)부영수증값을 검사하기 위한계좌이체에 대한 영수증값 부영수증값검사정보영수증값을 검사하기 위한 영수증값검사정보비밀키 y로 x를 디지털 서명한 값

제안 프로토콜의 수행 과정은 도 6과 같다. 먼저 고객은 인터넷으로 상점에 접속하여 물건을 구입한다. 지불 프로토콜의 수행에 앞서 고객은 CID, 거래할 상점의 MID, 거래할 신용기관의 TID, 지불정보 PI, 주문정보 OI를 결정한다. 그림에 표시되지는 않았지만 고객과 상점간, 상점과 신용기관 사이는 SSL로 안전한 채널이 제공된다.

1. 상점은 거래일련번호 MSEQ를 생성하고 고객에게 전송한다.

2. - ① 고객은 은행과의 사전등록에서 등록한 ID(이하 ID), 계좌번호와 계좌 비밀번호를 입력하고 현재시간을 입력한다.

② 현재 시각을 정수 값으로 표현한 TS로 변환한다.

③ PAI와 HS를 생성한다.

SEC = {ACC_NUMBER, ACC_PSWD}

IDS = {CID, MID, TID}

PAI = H_PSWD{ID, IDS, MSEQ, PI, H(OI), H(SEC,TS), TS}

④ ID, IDS, MSEQ, PI, OI, H(SEC, TS), TS, MAC를 상점에게 전송한다.

3. - ① 상점은 PI와 OI의 내용이 맞는 지 검사한다.

맞지 않으면 에러신호 ERR_OI를 생성한다.

② 에러가 없으면 ID, IDS, MSEQ, PI, H(OI), H(SEC, TS), TS, MAC를 신용기관으로 전송한다. 에러가 발생하면 상점은 S_M{MSEQ, ERR_OI}를 고객에게 전송하고 고객은 에러발생을 표시하고 프로토콜을 종료한다.

4. - ① 신용기관은 CH_PAI = H_PSWD{ID, IDS, MSEQ, PI, H(OI), H(SEC, TS), TS}를 계산한다.

② PAI와 ①에서 계산한 값을 비교한다.

PAI가 CH_PAI와 같은지 비교한다. 또한 이 단계에서 TS가 L_TS보다 큰지를 비교한다.

③ PAI가 CH_PAI와 같고, TS가 L_TS보다 크다면 지불을 승인하고 고객 계좌에서 PI에 해당하는 만큼의 금액을 상점의 계좌로 이체한다. 그리고 은행은 상점에게 지불승인번호 APPN과 HT를 전송한다.

HS = H(ID, IDS, MSEQ, PI, H(OI), SEC, TS)

HT = H(HS, APPN)

④ 만약 지불을 승인할 수 없다면 은행은 ERR_PAI, H(HS, ERR_PAI)를 상점으로 전송한다.

5. - ① 상점이 APPN, HT를 수신했다면 다음 단계를 수행한다. 상점이 에러신호를 수신했다면 ERR_PAI, H(HS, ERR_PAI)를 고객에게 전송하고 고객은 에러발생을 표시하고 프로토콜을 종료한다.

② 상점은 APPN, HT or NULL을 고객에게 전송한다.

③ 고객은 HS = H(ID, IDS, MSEQ, PI, H(OI), SEC, TS)를 생성한다.

④ 고객은 CH_HT를 계산하여 전송받은 HT와 같음을 확인한다. 두 값이 같다면 프로토콜은 정상적으로 종료되고 지불이 정상 처리되는 것을 의미한다. NULL을 받았다면 고객은 에러를 표시하고 위의 값을 저장하고 차후에 지불에 이의를 제기할 수 있다.

이하에서 도 7, 도 8 및 도 9를 참조하여 본 발명의 실시예를 상세히 설명한다.

도 7 및 도 8은 전자계좌이체에 의한 전자지불방법의 실시예의 순서도를 보이고 있다. 은행 컴퓨터는 지불자로부터 지불자비밀키(PSWD), 지불자비밀정보(SEC)를 포함하여 지불자아이디(ID)를 입력(701)받는다. 지불자는 지불자 컴퓨터를 통해 수불자 컴퓨터에 접속(702)하면, 수불자 컴퓨터는 지불자 컴퓨터에 거래번호(MSEQ) 와 수불자고유코드(MID)를 전송(703)한다. 지불자 컴퓨터는 은행에 등록된 지불자의 아이디(ID), 지불자비밀키(PSWD), 계좌코드(ACC_NUM), 계좌비밀코드(ACC_PSWD)와 지불정보(PI), 주문정보(OI), 거래시간을 정수값으로 나타낸 거래시간정수(TS)를 입력받거나 또는 컴퓨터 내부에서 생성하여 얻는다(704). 이렇게 얻어진 정보에 기초하여 지불승인정보(PAI)값이 계산되는데, 그 자세한 내용은 위 지불자아이디(ID), 고유코드정보(IDS), 거래코드(MSEQ), 지불정보(PI), 주문정보(OI)를 역변환이 불가능하도록 암호화한 값인 주문정보암호화값(COI), 지불자비밀정보(SEC) 및 거래시간정수(TS)를 역변환이 불가능하도록 암호화한 값, 거래시간정수(TS)를 입력값으로 하고 지불자비밀키(PSWD)를 킷값으로 하여 역변환이 불가능하도록 암호화한 값인 지불승인정보(PAI)를 계산(705)한다. 그 후 지불자아이디(ID), 고유코드정보(IDS), 거래코드(MSEQ), 지불정보(PI), 주문정보(OI), 지불자비밀정보(SEC) 및 거래시간정수(TS)를 역변환이 불가능하도록 암호화한 값, 거래시간정수(TS) 및 지불승인정보(PAI)를 수불자 컴퓨터로 전송(706)하게 된다. 여기서 지불자비밀정보(SEC)를 암호화하여 수불자 컴퓨터에게 전송하므로써 지불자의 계좌코드(ACC_NUM)와 계좌비밀코드(ACC_PSWD)의 값은 수불자에게 노출되지 않게된다. 위 정보를 수신한 수불자 컴퓨터는 지불정보(PI)와 주문정보(OI)를 비교하여 양자가 일치하는지를 검사(707)한다. 여기서 앞서의 양자가 일치하는 경우에는 지불자아이디(ID), 고유코드정보(IDS), 거래코드(MSEQ), 지불정보(PI), 주문정보암호화값(COI), 지불자비밀정보(SEC) 및 거래시간정수(TS)를 역변환이 불가능하도록 암호화한 값, 거래시간정수(TS), 지불승인정보(PAI)를 다시 은행 컴퓨터에 전송(708)한다. 이 단계에서 주문정보(OI)대신에 주문정보암호화값(COI)를 전송하므로써 고객의 주문정보(OI)는 은행에 노출되지 않게 된다. 위 707단계에서 지불정보(PI)와 주문정보(OI)의 값에이상이 있으면 주문에러정보(ERR_OI)를 생성하여, 이 주문에러정보(ERR_OI) 및 거래코드(MSEQ)를 수불자의 비밀키로 서명한 값을 지불자 컴퓨터로 전송(710)하고 지불자 컴퓨터는 에러정보를 표시(711)하고 계좌이체거래가 끝낸다(712). 위 710단계에서 수불자의 비밀키를 이용하여 서명한 값을 전송하므로써 수불자의 허위취소를 방지할 수 있게된다.

도 7에서 ①, ②, ③은 도 8의 ①, ②, ③으로 연결되어 전자지불방법의 실시예의 순서도가 계속된다. 위에서 지불자아이디(ID), 고유코드정보(IDS), 거래코드(MSEQ), 지불정보(PI), 주문정보암호화값(COI), 지불자비밀정보(SEC) 및 거래시간정수(TS)를 역변환이 불가능하도록 암호화한 값, 거래시간정수(TS), 지불승인정보(PAI)를 수신한 은행 컴퓨터는 수불 컴퓨터가 지불승인정보(PAI)를 계산한 방식과 동일한 방식으로 위에서 전송받은 정보를 이용하여 지불승인검사정보(CH_PAI)를 계산하여 이 값이 위 전송받은 지불승인정보(PAI)와 동일한지를 판단(801)한다. 이때 801단계에서 양자의 값이 동일하지 않은 경우에는 위 708단계에서 전송받은 지불자아이디(ID), 고유코드정보(IDS), 거래코드(MSEQ), 지불정보(PI), 주문정보암호화값(COI), 지불자비밀정보(SEC) 및 거래시간정수(TS)값을 입력값으로 하여 역변환이 불가능하도록 암호화한 값인 부영수증값(HS)를 계산하고, 지불승인에러정보(ERR_PAI)를 생성시키고, 이 지불승인에러정보(ERR_PAI), 위에서 계산한 부영수증값(HS)와 지불승인에러정보(ERR_PAI)를 입력값으로 하여 역변환이 불가능하도록 암호화한 값을 수불자 컴퓨터에 전송(802)한다. 수불자 컴퓨터는 이 전송받은 정보를 지불자 컴퓨터에 전송(803)하고, 지불자 컴퓨터는 지불자에게 에러정보를 제공하고 전자계좌이체 지불거래를 종료한다. 위 801단계에서 지불승인정보(PAI)에 이상이 없는 것으로 판단되면, 전송받은 지불정보(PI)에 따라 지불자 계좌에서 수불자계좌로 자금을 이체하고 지불승인코드(APPN)을 생성(806)시킨다. 위 자금을 이체하는 과정에서 에러가 발생하였는지 판단(807)하여 에러가 발생한 경우에는 널(NULL)값을 수불자 컴퓨터에 전송(808)하고, 수불자 컴퓨터는 다시 지불자 컴퓨터에 널(NULL)값을 전송(809)한다. 위의 널(NULL)값을 전송받은 지불자 컴퓨터는 에러정보를 지불자에게 제공하고, 차후에 지불자가 지불에 대한 이의를 제기하는데 근거가되는 현재의 전자계좌이체거래에 관련된 모든 데이터를 저장(814)하고 지불자에게 이러한 저장된 정보를 제공한다. 이로써 전자계좌이체 거래는 종료(815)된다. 위 807단계에서 에러가 발생하지 않은 것으로 판단되는 경우에는 708단계에서 전송받은 지불자아이디(ID), 고유코드정보(IDS), 거래코드(MSEQ), 지불정보(PI), 주문정보암호화값(COI), 지불자비밀정보(SEC) 및 거래시간정수(TS)값을 입력값으로 하여 역변환이 불가능하도록 암호화한 값인 부영수증값(HS)를 계산하고, 이 부영수증값(HS)와 지불승인코드(APPN)을 입력으로 하여 역변환이 불가능하도록 암호화한 값인 영수증값(HT)를 계산(810)한다. 여기서 지불자비밀정보(SEC)는 수불자 컴퓨터로부터 전송받은 지불자비밀정보(SEC)는 역변환이 불가능하도록 암호화되어 있으므로 이용될 수 없고, 은행에 미리 등록된 지불자비밀정보(SEC)가 이용된다. 이후 여기서 계산된 영수증값(HT)와 위의 지불승인코드(APPN)을 수불자 컴퓨터에 전송(811)하고, 수불자 컴퓨터는 다시 이를 지불자 컴퓨터로 전송(812)한다. 위 영수증값(HT) 및 지불자승인코드(APPN)을 전송받은 지불자 컴퓨터는 위 영수증값(HT)를 계산하는 방식과 동일한 방식으로 최초에 지불자 컴퓨터에서 입력받거나 발생키켜 얻은 정보에 기초하여 영수증값검사정보(CH_HT)를 계산하고 전송받은 영수증값(HT)와 비교하여 영수증값(HT)에 이상이 없는지를 판단(813)한다. 위 813단계에서 영수증값(HT)에 이상이 있는 것으로 판단되는 경우에는 에러정보를 지불자에게 제공하고, 지불자가 지불에 대한 이의를 제기하는데 근거가 되는 전자계좌이체 거래에 관련된 모든 정보를 저장(815)하고 이러한 정보를 지불자에게 제공한다. 이로써 전자계좌이체 거래는 종료(815)된다.

도 9는 전자계좌이체에 의한 전자지불 시스템을 보이고 있다. 지불자 컴퓨터는 입출력부, 연산부, 판단부, 송수신부로 구성되어 있으며, 은행서버는 판단부, 연산부, 계좌이체부, 송수신부로 구성되어 있고, 수불자 컴퓨터는 연산부, 판단부, 상품정보제공부로 구성되어 있다. 또한 지불자 컴퓨터는 거래정보를 저장하는 거래정보 저장부를 구비하고 있고, 수불자 컴퓨터는 상품정보를 저장하는 상품정보 저방부를 구비하고 있으며, 은행 서버는 계좌정보를 저장하는 계좌정보 저장부를 구비하고 있다. 이러한 지불자 컴퓨터, 수불자 컴퓨터 및 은행 서버(또는 컴퓨터)는 인터넷망 등 네트웍을 통하여 접속되어 있다.

이하에서 지불자 컴퓨터의 구성부분에 대하여 설명한다. 지불 컴퓨터의 입출력부는 은행에 등록된 지불자의 아이디(ID), 지불자비밀키(PSWD), 계좌코드(ACC_NUM), 계좌비밀코드(ACC_PSWD)와 지불정보(PI), 주문정보(OI)를 모니터, 마우스, 키보드 등의 입출력장치를 통하여 입력받고, 수불자 컴퓨터로부터 에러정보를 수신한 경우에는 출력장치를 통하여 에러정보를 지불자에게 제공한다. 지불 컴퓨터의 연산부는 거래시간을 정수값으로 나타낸 거래시간정수(TS)를 생성시키고, 지불승인정보(PAI)의 계산 및 영수증값검사정보(CH_HT)의 계산을 수행한다. 지불 컴퓨터의 판단부는 영수증값검사정보(CH_HT)와 영수증값(HT)와 비교하여 영수증값(HT)에 이상이 없는지를 판단한다. 지불자 컴퓨터의 송수신부는 지불자아이디(ID), 고유코드정보(IDS), 거래코드(MSEQ), 지불정보(PI), 주문정보(OI), 지불자비밀정보(SEC) 및 거래시간정수(TS)를 역변환이 불가능하도록 암호화한 값, 거래시간정수(TS) 및 지불승인정보(PAI)를 수불자 컴퓨터로 전송하고, 수불자 컴퓨터로부터 지불자에게 제공할 각종 상품 또는 서비스 정보, 전자계좌이체 거래 중에 발생한 각종 에러정보, 계좌이체가 성공적으로 이루어진 경우에는 지불승인코드(APPN) 및 영수증값(HT)를 수신한다. 지불자 컴퓨터에 구비된 거래정보 저장부에는 지불자 컴퓨터가 수불자 컴퓨터로부터 널(NULL)값을 수신한 경우에 그 때의 전자계좌이체 거래에 관련된 모든 정보가 저장된다.

이하에서 수불자 컴퓨터의 구성부분에 대하여 설명한다. 수불자 컴퓨터의 상품정보 제공부는 상품정보 저장부에 기록되어 있는 상품정보를 읽어 수불자 컴퓨터의 송수신부를 통하여 지불자 컴퓨터에 전송한다. 수불자 컴퓨터의 판단부는 지불정보(PI)와 주문정보(OI)를 비교하여, 이들이 상호 일치하는지 여부를 판단한다. 수불자 컴퓨터의 연산부는 위의 지불정보(PI)와 주문정보(OI)가 일치하지 않는 경우 에러정보들을 생성하고, 이러한 에러정보중 일부에 대하여 비밀키를 이용하여 서명한 값을 생성한다. 수불자 컴퓨터의 송수신부는 지불자 컴퓨터로부터 지불자아이디(ID), 고유코드정보(IDS), 거래코드(MSEQ), 지불정보(PI), 주문정보암호화값(COI), 지불자비밀정보(SEC) 및 거래시간정수(TS)를 역변환이 불가능하도록 암호화한 값, 거래시간정수(TS) 및 지불승인정보(PAI)를 수신하고 이를 은행 컴퓨터로 전송하며, 은행 컴퓨터로부터 에러정보들, 지불승인코드(APPN) 및 영수증값(HT)를 전송받고 이를 다시 지불자 컴퓨터로 전송한다.

이하에서 은행 컴퓨터(또는 서버)의 구성부분에 대하여 설명한다. 은행 컴퓨터의 계좌정보 저장부에는 지불자의 등록된 계좌에 대한 정보 및 지불자아이디(ID), 지불자비밀키(PSWD)에 관한 정보가 저장된다. 은행 컴퓨터의 송수신부는 수불자 컴퓨터로부터 지불자아이디(ID), 고유코드정보(IDS), 거래코드(MSEQ), 지불정보(PI), 주문정보암호화값(COI), 지불자비밀정보(SEC) 및 거래시간정수(TS)를 역변환이 불가능하도록 암호화한 값, 거래시간정수(TS) 및 지불승인정보(PAI)를 수신하고 각종 에러정보와 지불승인코드(APPN) 및 영수증값(HT)을 수불자 컴퓨터로 전송한다. 은행 컴퓨터의 판단부는 지불승인검사정보(CH_PAI)와 지불승인정보(PAI)를 비교하고, 또한 거래시간정수(TS)와 최후거래시간정수(L_TS)를 비교하여 지불을 승인할 것인지 여부를 판단하고, 지불을 승인하여 지불자 계좌에서 수불자 계좌로 금전을 이체할 때 에러가 발생하였는지를 판단한다. 은행 컴퓨터의 연산부는 수불자 컴퓨터로부터 전송받은 정보에 기초하여 지불승인검사정보(CH_PAI)를 계산하고, 계좌이체가 이상없이 이루어진 경우에는 부영수증값(HS)과 영수증값(HT)를 발생시키고, 위 과정중에서 에러가 발생한 경우에는 에러정보를 발생시킨다. 은행 컴퓨터의 계좌이체부는 지불이 승인된 경우에 지불정보(PI)에 따라 지불자 계좌에서 수불자 계좌로 자금을 이체하고 지불승인코드(APPN)을 발생시킨다.

한편, 상술한 본 발명의 실시예들은 컴퓨터에서 실행될 수 있는 프로그램으로 작성 가능하다. 그리고, 컴퓨터에서 사용되는 매체를 이용하여 상기 프로그램을 동작시키는 범용 디지털 컴퓨터에서 구현될 수 있다. 상기 매체는 마그네틱 저장매체(예를 들면, 롬, 플로피 디스크, 하드 디스크 등), 광학적 판독 매체(예를 들면, 씨디롬, 디브이디 등) 및 캐리어 웨이브(예를 들면, 인터넷을 통한 전송)와 같은 저장매체를 포함한다.

이제까지 본 발명에 대하여 그 바람직한 실시예들을 중심으로 살펴보았다. 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 실시예들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.

본 발명에서 제안하는 프로토콜의 효율성을 알아보기 위해 기존의 프로토콜과 pass 수, 연산량, 데이터 저장량 등의 측면에서 비교하여 표 7에 나타내었다.

	SSL기반의전자지불 프로토콜	제안하는 SSL기반의전자계좌이체 프로토콜
프로토콜 참여자	고객, 상점, 신용기관	고객, 상점, 신용기관
추가 Pass 수	4	5
주요 연산량	SSL의 연산량	SSL의 연산량hashing(MAC포함) 9회
데이터 저장량	거래기록	거래기록 + MSEQ + TS +H( OI ) (신용기관)

위의 표 7의 결과에 따르면 본 발명에서 제안한 프로토콜은 기존 프로토콜에 비하여 한번의 pass, 2회의 MAC 연산과 7회의 hash 연산만을 필요로 한다. hash의 10000회 연산은 공개키 암호방식인 RSA 서명생성 1회, RSA 서명확인 100회 정도의 연산에 비교될 정도로 아주 작은 연산량을 가지므로 소액지불에서의 연산량 문제를 해결함으로써 처리비용을 줄일 수 있는 장점이 있다. 즉 약간의 추가 연산만으로 고객의 정보를 악의의 상점들로부터 보호할 수 있다. 다만, 표 7에서 주요 연산량을 비교할 때 에러 발생의 경우를 제외하고 거래가 정상적으로 이루어 졌을 때만 간주하였다.

또한 본 발명에서 제안한 프로토콜에 대한 공격을 분석하여 보면, 앞서 언급한 것처럼 본 발명에서 제안하는 프로토콜에 대한 공격도 상점의 내부자에 의한 공격과 상점 외부자에 의한 공격으로 나눌 수 있다. 상점 내부자에 의한 공격의 경우 표 8에서 예상되는 공격유형과 본 발명이 제안하는 프로토콜의 그에 대한 대응을 정리하였다.

공격 유형	제안하는 프로토콜의 대응
고객 비밀정보SEC의 유출	SEC는 해쉬되어 상점에게 전달되므로 상점내부자는 SEC를 알 수 없다.
메시지의재사용	신용기관이 저장하고 있는 고객의 마지막 거래시각 값이 TS보다 같거나 크면 신용기관은 거래를 승인하지 않는다.
지불정보, 주문정보에 대한 조작	지불 정보(PI)와 주문정보(OI)는 조작을 하더라도 은행이 받은 MAC와 그 내용이 달라지므로 지불승인을 받을 수가 없게된다.
허위 승인	고객의 신용정보를 모르면 HT를 생성할 수 없다.
허위 취소	에러메시지를 상점의 비밀키로 디지털 서명하여 보내므로 허위취소에 대한 부인봉쇄를 할 수 있다.

한편 상점 외부자에 의한 공격의 경우에는, 128-bit SSL에 대한 공격은 현재의 기술로 풀기 어렵다. 따라서, 모든 프로토콜에서의 128-bit SSL이 사용되었다고 가정하면 상점 외부자에 의한 공격은 불가능하다.

이상에서 본 발명에서 제안하는 프로토콜과 기존의 프로토콜을 비교하여 보았다. 현재 많이 사용되는 SSL기반의 전자지불 프로토콜은 고객의 신용정보가 쇼핑몰에게 그대로 노출된다는 보안상의 문제점을 가지고 있는바, 이러한 문제점은 SSL이 전자지불시스템으로 고안된 프로토콜이 아니기 때문에 가지는 본질적인 문제이므로 SSL을 전자지불환경에 맞도록 개선함이 필요하다.

본 발명에서는 연산량이 작은 MAC와 해쉬함수를 이용하여 고객 신용정보를 신용기관만이 알 수 있도록 함으로써 고객정보 유출의 위험성으로부터 안전하며 소액에 적용 가능한 전자계좌이체 프로토콜을 제안하였다. 제안한 SSL기반의 전자계좌이체 프로토콜은 기존 프로토콜과 유사하여 기존 시스템을 최대한 이용할 수 있다. 또한 기존 프로토콜에 비해 추가적인 연산량과 데이터 저장량 등이 적어서 시스템 구축비용이 적게 든다. 제안한 프로토콜을 디지털 콘텐츠 거래 등과 같은 안전한 소액지불시스템이 필요한 곳에 유용하게 쓰일 수 있을 것이다.

도 1은 에스에스엘(SSL : secure socket layer) 프로토콜(protocol)의 구조를 보이고 있다.

도 2는 에스에스엘 프로토콜의 핸드쉐??(Handshake) 동작을 보이고 있다.

도 3은 에스에스엘 레코드(record) 프로토콜 동작을 보이고 있다.

도 4는 에스에스엘 기반 전자지불 프로토콜을 보이고 있다.

도 5는 고객과 은행의 사전등록절차를 보이고 있다.

도 6은 맥(MAC)을 이용한 에스에스엘(SSL) 기반 전자계좌이체 프로토콜을 보이고 있다.

도 7 및 도 8은 전자계좌이체에 의한 전자지불방법의 실시예의 순서도를 보이고 있다.

도 9는 전자계좌이체에 의한 전자지불 시스템을 보이고 있다.

Claims (20)

1. (a) 계좌정보저장부가 지불자로부터 지불자비밀키(PSWD), 지불자계좌코드(ACC_NUM)와 지불자계좌비밀코드(ACC_PSWD)로 구성되는 지불자비밀정보(SEC)를 포함하는 정보를 등록받는 단계;

   (b) 송수신부가 상기 지불자의 컴퓨터로부터 상기 지불자 컴퓨터에서 상기 지불자비밀키(PSWD)를 킷값으로 하고 상기 지불자비밀정보(SEC), 지불정보(PI), 주문정보(OI) 및 거래시간을 나타내는 시간정보(TS)를 포함하는 정보를 입력값으로 하여 암호화하여 생성된 지불승인정보(PAI)와, 상기 지불자비밀정보(SEC)와, 상기 지불정보(PI)와, 상기 주문정보(OI)와, 상기 시간정보(TS)를 포함하는 정보를 수신한 수불자 컴퓨터로부터 상기 지불승인정보(PAI)와, 상기 지불자비밀정보(SEC)와, 상기 지불정보(PI)와, 상기 주문정보(OI)와, 상기 시간정보(TS)를 포함하는 정보를 전송받는 단계;

   (c) 연산부가 상기 등록된 지불자비밀키값(PSWD)을 킷값으로 하고 상기 전송받은 상기 지불자비밀정보(SEC), 상기 지불정보(PI), 상기 주문정보(OI) 및 상기 시간정보(TS)를 포함하는 정보를 입력값으로 하여 암호화하여 계산한 지불승인검사정보(CH_PAI)값을 구하는 단계;

   (d) 판단부가 상기 전송받은 지불승인정보(PAI)와 상기 계산된 지불승인검사정보(CH_PAI)값을 비교하여 상기 전송받은 지불승인정보(PAI)에 이상이 없는지를 검사하고, 상기 시간정보(TS)가 상기 지불자의 최종거래시간보다 이후를 나타내는지를 확인하는 단계; 및

   (e) 계좌이체부가 상기 (d)단계에서 지불승인정보(PAI)에 이상이 없고, 상기 시간정보(TS)가 상기 지불자의 최종거래시간보다 이후를 나타내면 상기 지불정보(PI)에 따라 지불자 계좌에서 수불자 계좌로 자금을 이체하고, 상기 시간정보(TS)를 상기 지불자의 최종거래시간정보로 저장하는 단계를 포함하는 것을 특징으로 하는 전자계좌이체방법.
2. 제1항에 있어서, 상기 지불자비밀정보(SEC)는 수불자에게 지불자의 비밀정보가 노출되지 않도록 지불자의 비밀정보를 포함하는 정보를 입력값으로 하여 역변환이 불가능하도록 암호화된 상태로 전송되는 것을 특징으로 하는 전자계좌이체방법.
3. 제1항에 있어서, 상기 (b)단계에서 상기 수불자 컴퓨터로부터 전송되는 상기 주문정보(OI)는 은행에 주문정보(OI)가 노출되지 않도록 주문정보(OI)를 입력값으로 하여 역변환이 불가능하도록 암호화된 상태로 전송되는 것을 특징으로 하는 전자계좌이체방법.
4. 제1항에 있어서, 상기 (e)단계는

   (ea)상기 지불자 계좌에서 수불자 계좌로 자금을 이체한 후에는 지불승인코드(APPN)을 발생시키고 상기 지불정보(PI), 상기 주문정보(OI) 또는 주문정보암호화값(COI), 상기 은행 컴퓨터에 등록된 지불자비밀정보(SEC)를 포함하는 정보를 입력값으로 하여 역변환이 불가능하도록 암호화한 값과 상기 지불승인코드(APPN)을 입력으로 하여 역변환이 불가능하도록 암호화한 영수증값(HT)를 구하고, 상기 지불승인코드(APPN) 및 상기 영수증값(HT)를 수불자컴퓨터에 전송하는 단계;

   (eb) 수불자 컴퓨터는 전송받은 상기 지불승인코드(APPN) 및 상기 영수증값(HT)을 지불자 컴퓨터에 전송하는 단계;

   (ec) 지불자 컴퓨터는 상기 지불정보(PI), 상기 주문정보(OI) 또는 상기 주문정보(OI)를 암호화값(COI), 상기 지불자비밀정보(SEC)를 포함하는 정보를 입력값으로 하여 역변환이 불가능하도록 암호화한 값과 전송받은 상기 지불승인코드(APPN)을 입력으로 하여 역변환이 불가능하도록 암호화한 영수증값검사정보(CH_HT)를 구하고, 상기 전송받은 영수증값(HT)와 비교하여 이상이 없는지를 검사하여 지불결과를 지불자에게 제공하는 단계를 더 포함하는 것을 특징으로 하는 전자계좌이체방법.
5. 제1항에 있어서, 상기 전자계좌이체 방법은

   (a1) 상기 수불자컴퓨터가 상기 주문정보(OI)에 따라 지불정보(PI)가 정당한지 여부를 검사하여 이상이 있는 경우에는 에러정보를 생성하고, 수불자의 비밀키를 이용하여 서명한 값을 상기 지불자 컴퓨터에 전송하는 단계;

   (a2) 상기 (d)단계에서 상기 지불승인정보(PAI)에 에러가 있는 경우에는 그에 대응하는 에러정보를 생성하여 수불자 컴퓨터로 전송하고, 상기 수불자 컴퓨터는 상기 에러정보를 지불자 컴퓨터로 전송하는 단계;

   (a3) 상기 (e)단계에서 상기 자금이체에 에러가 있는 경우에는 그에 상응하는 에러정보를 생성하여 수불자 컴퓨터로 전송하고, 상기 수불자 컴퓨터는 상기 에러정보를 지불자 컴퓨터로 전송하는 단계;

   (a4) 상기 (a1),(a2) 및 (a3)단계에서 상기 에러정보를 수신한 지불자 컴퓨터는 에러정보 및 지불자가 지불을 거부하거나 취소하는데 근거가 되는 에러정보를 수신할 당시의 거래관련정보를 지불자에게 제공하는 단계를 더 포함하는 것을 특징으로 하는 전자계좌이체방법.
6. (a) 입출력부가 은행에 등록된 지불자비밀키(PSWD) 및 계좌코드(ACC_NUM)와 계좌비밀코드(ACC_PSWD)로 구성되는 지불자비밀정보(SEC), 지불금액등의 지불정보(PI), 구매상품 등의 주문정보(OI)를 포함하는 정보를 얻는 단계;

   (b) 연산부가 상기 지불자비밀키(PSWD)를 킷값으로 하고 상기 지불자비밀정보(SEC), 상기 지불정보(PI), 상기 주문정보(OI) 및 거래시간을 나타내는 시간정보(TS)를 포함하는 정보를 입력값으로 하여 암호화한 지불승인정보(PAI)를 생성하는 단계;

   (c) 송수신부가 상기 지불승인정보(PAI)와, 상기 지불자비밀정보(SEC)와, 상기 지불정보(PI)와, 상기 주문정보(OI)와, 상기 시간정보(TS)를 포함하는 정보를 수불자 컴퓨터로 전송하는 단계;

   (d) 상기 송수신부가 은행 컴퓨터에서 계산된 대금지불에 대한 영수증값(HT) 및 지불승인코드(APPN)을 전송받는 단계;

   (e) 연산부가 상기 (a)단계에서 얻은 상기 지불정보(PI), 상기 주문정보(OI) 또는 상기 주문정보(OI)를 암호화값(COI), 상기 지불자비밀정보(SEC)를 포함하는 정보를 입력값으로 하여 암호화한 값과 전송받은 상기 지불승인코드(APPN)을 입력으로 하여 암호화한 영수증값검사정보(CH_HT)를 구하는 단계; 및

   (f) 판단부가 상기 전송받은 영수증값(HT)와 비교하여 이상이 없는지를 검사하여 지불결과를 지불자에게 제공하는 단계를 포함하는 것을 특징으로 하는 전자계좌이체에 의한 지불방법.
7. 제6항에 있어서, 상기 (b)단계의 지불승인판단정보(PAI)는

   상기 (a)단계에서 지불자아이디(ID), 지불자의 고유코드(CID), 수불자의 고유코드(MID), 은행의 고유코드(TID)로 구성되는 고유코드정보(IDS), 거래코드(MSEQ), 거래시간을 정수로 나타낸 거래시간정수(TS)에 관한 정보를 추가로 얻고,

   상기 지불자아이디(ID), 지불자의 고유코드(CID), 수불자의 고유코드(MID), 은행의 고유코드(TID)로 구성되는 고유코드정보(IDS), 거래코드(MSEQ), 지불정보(PI), 주문정보(OI)의 해쉬값, 상기 지불자의 계좌코드(ACC_NUM) 및 계좌비밀코드(ACC_PSWD)로 구성되는 지불자비밀정보(SEC)와 거래시간을 정수로 나타낸 거래시간정수(TS)의 해쉬값 및 상기 거래시간정수(TS)를 입력으로 하고 지불자비밀키(PSWD)를 키값으로한 해쉬함수의 값을 구함으로써 지불승인판단정보(PAI)를 계산하는 것을 특징으로 하는 전자계좌이체에 의한 지불방법.
8. 제6항에 있어서, 상기 (c)단계이후 (d)단계이전에

   입출력부가 수불자 컴퓨터로부터 에러정보를 수신한 경우에는 상기 에러정보 및 지불자가 지불을 거부하거나 취소하는데 근거가 되는 에러정보를 수신할 당시의 거래관련정보를 지불자에게 제공하는 단계를 더 포함하는 것을 특징으로 하는 전자계좌이체 에 의한 지불방법.
9. 삭제
10. 삭제
11. 삭제
12. 삭제
13. 삭제
14. 삭제
15. 제1항에 있어서, 상기 전자계좌이체방법은

    상기 계좌이체부가 지불자 계좌에서 수불자 계좌로 자금을 이체한 후에는 지불승인코드(APPN)을 발생시키는 단계;

    상기 연산부가 상기 지불정보(PI), 상기 주문정보(OI) 또는 주문정보암호화값(COI), 상기 은행 컴퓨터에 등록된 지불자비밀정보(SEC)를 포함하는 정보를 입력값으로 하여 역변환이 불가능하도록 암호화한 값과 상기 지불승인코드(APPN)을 입력으로 하여 역변환이 불가능하도록 암호화한 영수증값(HT)를 구하는 단계; 및

    상기 송수신부가 상기 지불승인코드(APPN) 및 상기 영수증값(HT)를 수불자컴퓨터에 전송하는 단계를 더 포함하는 것을 특징으로 하는 전자계좌이체방법.
16. 제15항에 있어서, 상기 영수증값(HT)는

    상기 지불자아이디(ID), 지불자의 고유코드(CID), 수불자의 고유코드(MID), 은행의 고유코드(TID)로 구성되는 고유코드정보(IDS), 거래코드(MSEQ)를 수불자 컴퓨터로부터 더 전송받고, 상기 전송받은 지불자아이디(ID), 고유코드정보(IDS), 수불자의 거래코드(MSEQ), 지불정보(PI), 주문정보(OI)의 해쉬값, 지불자의 계좌코드(ACC_NUM) 및 계좌비밀코드(ACC_PSWD)로 구성되는 지불자비밀정보(SEC), 거래시간정보(TS)를 입력으로 한 해쉬함수값과 상기 지불승인코드(APPN)을 입력으로 한 해쉬함수값을 구함으로써 대금지불에 대한 영수증값(HT)를 구하는 것을 특징으로 하는 전자계좌이체방법.
17. 제1항에 있어서, 상기 (c)단계는

    상기 지불승인검사정보(CH_PAI)값과 상기 지불승인정보(PAI)값이 동일하지 않은 경우에, 지불승인에러정보(ERR_PAI) 및 상기 지불정보(PI), 상기 주문정보(OI) 또는 주문정보암호화값(COI), 상기 은행 컴퓨터에 등록된 지불자비밀정보(SEC)를 포함하는 정보를 입력값으로 하여 역변환이 불가능하도록 암호화한 값과 지불승인에러정보(ERR_PAI)를 입력으로 하는 해쉬함수값 및 상기 지불승인에러정보(ERR_PAI)를 수불자 컴퓨터에 전송하는 단계인 것을 특징으로 하는 전자계좌이체방법.
18. 제1항에 있어서, 상기 (e)단계는

    상기 지불자의 계좌에서 상기 수불자 계좌로 상기 지불정보(PI)에 해당하는 금액을 이체하는데 있어서 에러가 발생한 경우에, 작업을 취소하고 이체에러정보를 수불자 컴퓨터로 전송하는 것을 특징으로 하는 전자계좌이체방법.
19. 삭제
20. 제1항 내지 제8항 및 제15항 내지 제18항 중 어느 한 항의 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체.