Web Security and Payments
Web Security and Payments
WWW(World Wide Web)을 한마디로 요약해서 말한다면 분산 하이퍼미디어 정보검색
시스템이라고 표현할 수 있다. 여기서 하이퍼미디어란 용어는 하이퍼텍스트와
멀티미디어의 개념이 통합된 것으로, WWW을 이용하면 세계 각지에 분산되어 존재하는
텍스트, 그래픽, 영상, 그리고 사운드 등으로 구성되는 멀티미디어 정보를 동적으로
검색할 수 있는 서비스를 제공 받을 수 있다.
WWW의 역사는 1989년 3월 유럽의 물리학연구소인 CERN에서 여기저기 산재해 있는
다양한 정보들을 효율적으로 사용할 목적으로 Tim Berners Lee에 의해 시작된
프로젝트로 부터 유래한다. 이후 CERN에서 또 다른 프로젝트인 하이퍼텍스트 프로젝트가
수행되어 1990년 말경 하이퍼텍스트 문서 처리기술이 개발되었고 그 결과가 1991년
하이퍼텍스트*91 컨퍼런스에 소개되었으며, 1992년 WWW라는 이름으로 발표되었다.
최초의 WWW은 텔넷으로 접속하여 이용하는 형태이었으므로 이미 사용되고 있던
메뉴방식의 정보검색 서비스를 제공하던 고퍼(gopher)에 밀려 별로 주목받지 못하였다.
그러나 1993년 6월 미국 NCSA(National Center for Supercomputing Applications)의
마크 안드레슨이 WWW 서비스를 위한 사용자 인터페이스인 모자익(Mosaic)을 개발,
발표하면서 WWW은 급격히 주목받기 시작하였다. 이후 1994년 NCSA를 퇴직한
마크 안드레슨은 짐 클라크와 함께 넷스케이프사를 설립하고 넷스케이프(Netscape)라는
새로운 브라우저를 발표하여 현재 세계의 브라우저 시장을 석권하고 있다.
WWW은 하이퍼미디어 문서를 작성할 수 있도록 하는 표준언어인
HTML(HyperText Markup Language)과 HTML로 작성된 문서를 클라이언트와 서버 사이에
전송할 수 있게 해주는 통신 프로토콜인 HTTP(HyperText Transfer Protocol),
그리고 WWW 시스템이 인지할 수 있는 주소지정 문법인 URL(Uniform Resource Locator)을
주요 구성요소로 한다. 이밖에도 클라이언트에서 영상, 사운드 정보등을 사용자에게
표현해 주는 외부 표시기(External Viewer)가 있다. WWW의 동작모델은 (그림 1)과 같이
나타낼 수 있다.
(그림 1) WWW 동작모델
WWW 클라이언트에서 일어날 수 있는 위협의 한 형태로는 사용자에게 그래픽 인터페이스를
제공해 주는 브라우저 또는 브라우저와 함께 사용되는 외부표시기(Ecternal Viewer)에
존재할 수 있는 보안구멍(Security Hole)을 찾아내 브라우저 및 사용자 컴퓨터에 비인가된
접근을 시도할 수 있다. 특히 인터넷에서 개발되어 공개되는 외부표시기 프로그램에
누군가가 악의적으로 보안구멍을 만들어 배포한다면 이 공개 프로그램을 사용하는 사용자
컴퓨터는 그대로 보안 위협에 노출되게 된다. 이러한 위협을 막기 위해서는 사용되는
각종 프로그램에 보안구멍이 존재하지 않는지 주의 깊게 살펴보아야 하며, 이는 CERT등과
같이 각종 보안위협에 대한 정보 및 대응방안을 제공해 주는 관련 게시판이나 뉴스
그룹으로 부터 도움을 받을 수 있다.
또 다른 위협의 형태로는 불법적인 서버에 의해 클라이언트가 공격 받을 수 있다.
약간의 전문지식만 있으면 어떤 사용자도 손쉽게 WWW 서버를 설치할 수 있기 때문에,
악의를 가지고 서버를 설치하여 이 서버에 접속을 시도하는 클라이언트 정보를 빼내거나
클라이언트 시스템을 손상시킬 수도 있다. 이는 클라이언트 측에서 보았을 때 하이퍼
링크의 반대쪽에 위치한 서버가 정당한 서버인지 불법적인 서버인지를 알 수 없기 때문에
상대방에 대한 인증 기능이 없다면 이러한 위협에 상당히 취약한 특성을 갖는다. 이러한
위협에 대한 보호 방안으로는 Java와 같이 클라이언트에서 실행되는 프로그램의 안전성을
보장해 줄 수 있는 새로운 언어를 이용하는 방안과, 클라이언트에 대한 접근을 제한할 수
있도록 방화벽(Firewall) 시스템이나 프락시(Proxy)를 설치하는 방안이 있다. 그러나
방화벽 시스템을 사용하는 경우에도 트로이목마를 포함하는 WWW 문서에 대해서는
보호할 수 없다.
3.2 WWW 서버
서버에서의 가장 큰 보안 취약성은 CGI(Common Gateway Interface) 프로그램에 있다.
CGI는 URL에 의해 지정된 서버 측의 프로그램을 실행해 클라이언트 측의 자료를 전송하거나
서버 측의 자료를 전송받는 등의 작업을 위해 만들어진 인터페이스로 많은 CGI 응용
프로그램이 개발되어 있다. 사용자는 서버측의 특정 디렉토리를 지정하여 특정 프로그램을
실행할 수 있으므로 보안 측면에서 볼때 이것은 큰 취약성을 제공할 수 있다.
따라서 CGI 프로그램을 사용할 때에는 몇가지 주의사항이 요구되는데 먼저, CGI 프로그램이
들어갈 디렉토리를 특정 디렉토리로 제한하고 서버 셋업시 CGI 프로그램이 실행될 수 있는
디렉토리를 명확히 지정하는 것이 필요하다. NCSA 서버의 경우 access.conf 화일에
ExecCGI옵션을 이용하여 CGI 프로그램이 존재할 디렉토리를 지정할 수 있다[2].
또 다른 방안으로는 확인되고 검증된 CGI 프로그램 만을 사용하도록 제한할 필요가 있으며,
이는 안전한 CGI Script 작성법[3] 등을 참조하면 도움을 얻을 수 있다.
이밖에 서버 프로그램(httpd)을 실행시킬때 루트 권한으로 실행시키지 않아야 하며,
서버의 실행 디렉토리도 제한된 화일 시스템으로 지정하는 것이 안전하다.
또한 가능하면 HTTP 프로토콜 요소중 POST 방식의 사용을 제한하는 것이 좋다.
4.1 기본 인증(Basic Authentication)
이 방식은 HTTP 1.0 규격에서 정의되고 있으며 대부분의 브라우저와 서버가 이를 구현하고 있다. 기본인증 방식은 사용자 ID와 대응되는 패스워드 정보를 암호화한 상태로 서버가 저장하고 있다가 접속을 시도하는 사용자의 패스워드 정보를 확인하여 접속 여부를 허용하는 방식이다. 이 경우 단순하다는 장점은 있으나 사용자 패스워드가 단순히 uuencode되어 서버로 전송되므로 보안에 상당히 취약하게 되며, 서버는 사용자 ID와 패스워드 정보를 관리해야 하는 부담이 있다. 기본 인증 절차는 (그림 2)와 같다.
(그림 2) 기본 인증 방식
클라이언트 시스템 마다 고유의 망주소(IP Address)를 가지므로 이 주소 정보를
이용하여 서버에의 접속을 제어할 수 있다. 이 방식은 일반적으로 패켓 필터링이라고
부르는 기술을 사용하여 구현되며, 특히 망 주소의 구조적 특성을 이용하여 특정
도메인에 속하는 클라이언트 집합에 대해서도 손쉽게 접근제어가 가능하다.
그리고 이 방식을 이용함으로써 사용자 ID와 패스워드를 도용하여 접속을 시도하는 위협을
어느 정도 차단 가능하므로 현재 널리 사용되고 있다. 망 주소를 이용하는 접근제어의
예로써, NCSA 서버의 경우 access.conf 화일에 특정 IP 주소 및 도메인에 대한 서버에의
접속을 허용 또는 거부할 수 있도록 지정하는 기능을 제공한다.
4.3 메세지 다이제스트 인증(MD Authentication)
이 방식은 기존의 기본 인증방식에 일방향 특성을 갖는 메세지 다이제스트 함수를 적용,
사용자 정보를 암호화 하여 서버에 전송하는 방법으로 기존 기본 인증방식의 단점을
보완하고 있다. 즉, 사용자 ID 및 패스워드 정보를 MD5와 같은 일방향 함수로 다이제스트
하여 서버에 전송하면 서버에 이미 저장되어 있는 정보와 이를 비교하여 사용자를
인증하게 된다. 이때 재연(Replay) 공격을 막기위해 Timestamp 정보를 함께 보내는 것이
일반적이다. 메세지 다이제스트 인증 모델은 (그림 3)과 같다.
(그림 3) 메세지 다이제스트 인증 모델
NCSA 서버 프로그램에는 logs라는 디렉토리가 있고, access.log와 error.log라는 화일이
있다. 이 화일들을 이용하면 접근자, 접근한 문서, 접근실패시 이유 등을 알 수 있으며,
이들 정보를 이용하여 보안사고를 복구할 수 있다.
(그림 4) 계층별 보안기법
SSL은 넷스케이프사의 Kipp Hackman과 Taher Elgamal에 의해 개발된 프로토콜로,
특정 응용을 위한 보안 프로토콜이 아닌 일반적인 인터넷 보안 프로토콜로 사용될 수 있다.
즉, SSL은 (그림 5)에 표시된 바와 같이 인터넷 응용과 TCP/IP 통신 프로토콜 계층 사이에
존재하는 프로토콜이므로 WWW을 위한 HTTP 뿐만 아니라 Telnet, FTP등 다른 응용도
사용 가능하다.
(그림 5) SSL의 계층 모델
(그림 6) SSL의 동작 모델
5.2 S-HTTP(Secure-HTTP)
S-HTTP는 EIT(Enterprise Integration Technologies)의 Allan Schiffman과 Eric Rescorla에
의해 정의된 프로토콜로 기존 HTTP에 보안 기능을 추가하기 위해 확장되었다. S-HTTP에 의해
제공되는 보안 서비스는 다음과 같다.
(그림 7) S-HTTP의 동작 모델
(1) 사용자 A는 웹 서버로 일반적인 HTTP 요구 메시지를 전송한다.
(2) 사용자B가 속한 시스템상의 웹 서버는 평문 형태로는 메시지를 전송하지 않음을
지시하기 위해 다음과 같은 응답 메시지를 전송한다.
(3) 사용자 A는 수신된 응답 메시지중의 인증서 정보를 통해 사용자 B의 공개키를
획득하게 된다.
(4) 사용자 A는 이후 사용자 B로부터 수신된 암호문을 복호하기 위해 사용될 암호키를
생성하고, 이를 전송하기 위해 다음과 요구 메시지를 구성한다. 이때 Key-Assign 헤더의
마지막 영역이 16진수로 표현된 암호키이다.
(5) 과정 (4)에서 형성된 요구 메시지는 다음과 S-HTTP 요구 메시지로 캡슐화된다.
이때 BEGIN과 END 사이에 포함된 값이 과정 (4)에서 구성된 메시지를 과정 (2)에서 획득된
인증서에 포함된 B의 공개키로RSA 방식을 사용해서 암호화한 것이다.
(6) 사용자 B는 자신의 비밀키로 S-HTTP 요구 메시지의 내용영역의 RSA로 암호화된 값을
복호화한다. 그후에 HTTP 응답 메시지를 구성하고, S-HTTP 응답 메시지의 내용 영역으로
캡슐화되어서 전송되게 된다. 다음은 캡슐화된 S-HTTP 응답 메시지를 나타낸다.
이때 Prearranged-Key-Info 헤더에서 16진수 값이 이후 사용자 A로부터 수신된 암호문을
복호하기 위해 사용될 암호키를 의미하며, inband:key-1와 매칭되는 키로des-ecb
알고리즘을 사용하여 암호화한 문장이다.
S-HTTP의 몇가지 중요한 특징을 보면 먼저, 새로운 프로토콜 지시자로 "shttp"를 사용한다.
즉, S-HTTP로 접속하고자 할때 사용되는 URL은 "shttp://www.server.com/document.html"
형태가 된다. 둘째, 새로운 프로토콜 방법으로 Secure를 정의하고 있는데, S-HTTP 요청
메세지의 첫번째 줄은 "Secure * Secure-HTTP/1.1"과 같은 형태가 된다. 셋째, 하이퍼링크
앵커는 서버 식별, 요구되는 암호 매개변수 등을 지시한다. 또한 CERTS와 CRYPTOPTS라는
새로운 HTML 요소가 정의되어 사용된다.
5.3 PEP/SEA
SEA는 W3C(WWW Consortium)에서 개발되고 있는 프로토콜로, S-HTTP와 마찬가지로 기존
HTTP 프로토콜에 보안 기능을 확장하는 형태이다. S-HTTP는 HTTP를 확장한 프로토콜
이기는 하나 사실상 새로운 프로토콜 이므로 기존 HTTP와의 호환성에 문제가 있다.
따라서 W3C에서는 HTTP 프로토콜과 호환성을 가지며 보안 기능을 제공하도록 확장 가능한
형태의 프로토콜을 정의하기 위한 작업을 추진하고 있다. 현재 W3C에서는 기존 HTTP를
필요할 경우 사용자 수준에서 정의하여 확장할 수 있도록 하는 PEP(Protocol Extension
Protocol)를 정의하고 있는데, SEA(Security Extension Architecture)는 바로 이 PEP를
이용하여 WWW 보안기능을
제공하겠다는 개념이다. 다시말하면 PEP가 제공하는 확장성을 이용하여 SEA에 정의되는
보안 기능을 구현할 수 있도록 하는 접근방식을 고려하고 있다.
5.4 PGP/PEM-Web
PGP(Pretty Good Privacy)는 Phillip Zimmerman이 개발한 암호 패키지로 현재 전세계에서
전자메일 보안에 널리 사용되고 있다. PEM(Privacy Enhanced Mail)은 IETF에서 PGP를
기반으로 작성한 표준 전자메일 보안 프로토콜로 PGP와 유사한 기능을 제공한다. 많은
사용자들이 전자메일 보안을 위해 PGP또는 PEM을 사용하는 추세이므로 새로운 암호
프로토콜을 개발하지 않고도 PGP/PEM이 제공하는 암호화, 서명 및 키관리 기능등을
이용하여 쉽게 웹에 보안 기능을 제공할 수 있지 않겠느냐는 생각에서 이 방식이 연구되고
있다.
(그림 8) PGP/PEM-Web의 동작 모델
최근 인터넷 이용자가 급속히 성장함에 따라 인터넷을 본격적으로 상업적인 목적으로
이용하려는 시도가 늘고 있다.
Killen & Associates는 인터넷을 이용한 전자상거래의 규모가 2000년에는 6천억 달러,
2005년에는 1.25조 달러에 이를 것으로 예측하고 있다. 또한 International Data
Corporation에 따르면 가정에서 구매하는 사람의 비율이 1995년도의 28퍼센트에서
2000년에는 67퍼센트에 이를 것이며, 판매자의 비율도 1995년도의 19퍼센트 규모에서
2000년에는 45퍼센트에 이르는 급속한 성장을 할 것이라고 한다.
인터넷에서 전자상거래 서비스를 도입하기 위해 고려하여야할 사항들을 살펴보면 먼저,
인터넷을 통한 전자상거래시 구매자와 판매자가 안전하게 대금지불을 할 수 있도록
하게하는 전자지불(Electronic Payments, Digital Payments) 방식이 제공되어야 한다.
인터넷을 이용한 전자상거래가 본격 도입되기 위해 해결되어야 할 가장 중요한 사안중의
하나가 바로 안전한 전자지불 방식의 개발이다. 가장 단순한 형태의 전자지불 방식은
회원제로 운영되는 전자지불을 생각해 볼 수 있다.
이 방식은 고객이 미리 자신의 이름, ID, 비밀번호, 주소 등의 개인정보를 판매자에게
등록한 후 필요할 때에 자신의 ID와 비밀번호를 이용하여 서버에 접속한 다음
전자상거래 행위를 하는 방식이다. 구매에 대한 대금지불은 판매자가 구매 비용에
이용료를 부가하여 일정 기간 단위로 청구함으로써 이루어 질 수 있다.
7.1 전자지불 시스템 요구사항
전자지불 시스템에서 공통적으로 요구되는 요구사항으로써
인터넷 기반 지불 시스템이 가져야 할 특성에는 안정성, 기밀성, 유효성, 확장성, 익명성,
유연성, 효율성 등이 있으며 이러한 특성중에서 어떠한 것, 예를 들어 익명성 등은
전자현금 시스템에서 더욱 중요하게 고려되어야 할 요구사항이다.
일반적인 전자지불 시스템 요구사항으로는 다음과 같은 항목들이 있다.
(1) 기밀성(security) : 전자거래는 금융과 밀접한 관계가 있으며, 인터넷은 비교적
개방된 구조이기 때문에 해커로 부터 공격의 대상이 되기 쉽다. 그러므로 메세지가
도청당하거나 변경되기 쉬운 환경에서도 이러한 형태의 공격에 견딜수 있도록
안전하게 설계되어야 한다.
7.2 전자지불 시스템 모델
전자지불 시스템을 구성하기 위한 시스템 모델은 신용카드 기반 지불중재자(Payment
Broker) 시스템과, 전자화폐 시스템으로 나눌 수 있고, 전자화폐를 이용하는 방식은
다시 전자현금(Electronic Cash, Digital Cash) 기반 지불 시스템과 전자수표(Electronic
Cheque) 기반 지불 시스템, 그리고 소액 전자지불을 목적으로 설계된 소액 전자지불
(Micro-Payments) 시스템으로 구분해 볼 수 있다.
7.2.1 신용카드 기반 전자지불 시스템
신용카드 기반 지불중재자 시스템은 이미 널리 사용되고 있는 신용카드를 그대로
인터넷 전자상거래에 사용하려는 시도로 구매자와 판매자, 그리고 신용카드 회사 및
은행간을 서로 연결시켜 주는 지불중재자가 요구된다. 지불중재자는 Broker, Acquirer,
Gateway등으로 불리운다.
일반적인 지불중재자 시스템의 모델은 그림 9와 같다.
(그림 9) 지불중재자 시스템 모델
전자현금 기반 지불 시스템은 거래 당사자 간에 직접 전자적인 현금 정보가 오가는
형태로 구매자는 은행 등의 금융회사로 부터 자신의 계좌 잔고에 대해 또는
신용 기반으로 전자현금을 발급받아 이를 이용하여 대금지불을 하는 방식이다.
이 전자현금 정보를 받는 판매자는 이를 다시 다른 거래에 사용할 수도 있고, 은행에
지불요청을 하면 현금으로 자신의 계좌에 입금되게 된다.
7.2.3 전자수표 기반 전자지불 시스템
전자수표 기반 지불 시스템은 전자현금 시스템과 유사한 형태이기는 하나 구매자가
은행 등으로 부터 전자수표를 발급받아 이를 거래에 이용하는 방식으로 보통 거래시
전자수표의 유효성을 확인하기 위해 전자수표 발급자에게 이를 확인하는 과정이
요구된다. 대표적인 전자수표 시스템에는 CMU(카네기멜론 대학)에서 개발된 NetBill과
USC/ISI에서 개발한 NetCheque 등이 있다.
7.2.4 소액 전자지불 시스템
지금까지 언급된 전자지불 시스템들은 전자지불이 이루어지기 위해 요구되는 트랜젝션
비용 때문에 보통 5 ~ 10불 이상의 대금지불에 이용 가능한 방식들이다.
그러나 인터넷을 통한 전자거래의 상당 부분은 수 센트에서 수십 센트 단위로 발생되는
소액거래가 될 것으로 예측된다.
따라서 이러한 소액 전자지불에 적합한 전자지불 방식이 요구되고
있으며, 현재 개발되고 있는 대표적인 소액지불 시스템에는 DEC에서 개발된 Millicent,
Rivest와 Shamir가 제안한 Pay-Word와 MicroMint, 그리고 W3C에서 표준 프로토콜로
개발하고 있는 MPTP(MicroPayment Transfer Protocol) 등이 있다.
8.1 iKP(internet Keyed Payment)
iKP는 IBM이 개발한 신용카드 기반의 인터넷 전자지불 프로토콜로 공개키 기반 암호화
알고리즘을 이용하고 있다. iKP는 지불중재자 기반의 전자지불 시스템의
기본 개념을 잘 표현하고 있으며, 현존하는 비지니스 모델을 그대로 수용할 수 있다는
점에서 실제 적용가능한 지불시스템 방식이다. iKP의 개념은 SEPP와 SET 프로토콜 등에
반영되었으며, IBM Zurich Research Lab에서는 iKP에 근거하여 ZiP(Zurich iKP
Prototype)를 개발하였다.(http://www.zurich.ibm.com/Technology/Security)
(그림 10) iKP 지불시스템의 기본모델
8.2 SET(Secure Electronic Transaction Protocol)
SET 프로토콜은 최근 비자와 마스터카드가 각각 개발하던 전자지불 프로토콜을 통합하여
단일 규격으로 제안한 것으로써 인터넷 상에서 신용카드 기반의 전자지불을 위한 표준
프로토콜로 자리잡아 가고 있다. 1996년 2월에 초안이 발표된 이후 1996년 5월 확장된
SET 규격이 발표되었고, 1997년경에는 이에 따른 완전한 전자지불 시스템이 나올 것으로
기대하고 있다(http://www.mastercard.com/set/set.html).
(그림 11) SET 시스템 구조
(그림 12) 트랜젝션 단계
(그림 13) VeriFone's SET 구현제품의 메세지 흐름
NetBill은 카네기벨론 대학에서 연구용으로 개발된 전자수표형 지불시스템으로
트랜젝션 비밀성과 확장성을 제공하며, 특히 소액지불에 사용할 수 있다는
특징이 있다(http://www.ini.cmu.edu/netbill/). 또 하나 특기할 만한 사항은
NetBill에서는 온라인으로 전달될 수 있는 정보서비스 등에 대해서는
고객이 대금 지불을 완료할 때 까지 Merchant가 제공하는 정보를 볼 수 없게
하는 기능이 있다. NetBill 시스템의 트랜젝션 모델은 그림 14와 같다.
(그림 14) NetBill 시스템의 트랜젝션 모델
8.4 ecash
ecash는 네덜란드의 DigiCash사에 의해 개발된 최초의 온라인형 전자현금 시스템으로
전자화폐 시스템의 주요 요구사항인 익명성을 보장한다(http://www.digicash.com/ecash).
전자현금 시스템에서는 사용자에게 전자현금을 발행해 줄때 전자현금의 이중사용 방지
및 관리 등을 목적으로 일련번호를 부여하게 된다. 이때 은행은 발행하는 전자현금에
대한 사용자 정보를 취득하게 되고, 사용자가 이를 사용할 때 은행은 사용자의
현금 사용 상황을 추적하는 것이 가능해져 사용자의 프라이버시를 침해하게 된다.
ecash 전자지불 시스템은 Bank, Buyer, Merchant로 구성되며, RSA 공개키 암호
알고리즘을 사용한다. 각 사용자는 자신의 공개키 쌍을 소유하며 이를 이용하여 암호화
및 디지탈서명을 하게 된다. ecash 시스템에서 Buyer에 해당하는 Web 클라이언트측
소프트웨어를 Cyberwallet이라고 부르며, 이는 은행으로 부터 필요할 때에 전자현금을
발급받는 기능과, Merchant와 온라인으로 연결되어 전자거래시 전자현금을 지불하는
기능을 수행한다.
(그림 15) ecash의 전자지불 프로토콜
8.5 IC 카드 기반 전자지갑형 전자현금
앞서 소개한 ecash는 전자현금의 유효성을 은행에 온라인으로 접속하여 확인하는
과정이 필요하다. 최근 전자현금의 또 다른 형태로 주목을 받고있는 것이
기존에 지폐와 동전을 지갑에 넣어 가지고 다니는 것과 마찬가지로 IC 카드에
전자현금 정보를 저장하여 가지고 다니다가 필요할 때에 은행에 조회하는 과정을
거치지 않고 바로 전자현금을 사용할 수 있도록 하는 방식이 개발되어 실용화 되는
단계에 있다. 이런 IC 카드 기반의 전자지갑형 전자현금을 전자현금 카드,
전자화폐 카드, 전자지갑이라고 부르고 있다. 전자화폐 카드는 현금과 마찬가지로
분실하면 손실이 발생하게 된다.
전자화폐 카드는 기존의 신용카드가 소액 거래시 사용이 불편했던 단점을 해결할 수
있는 편리한 대금지불 수단으로 급속히 확대되고 있다. 대표적인 전자화폐 카드로는
영국에서 대규모 시험을 거쳐 실용화 단계에 이른 몬덱스(Mondex)와 벨기에에서
사용되고 있는 프로톤(Proton) 등을 들 수 있다(http://www.mondex.com/index.html).
실제 몬덱스나 프로톤을 이용하여 쇼핑을 하고 대금을 전자화폐 카드로 지불하면
수초 이내에 매장에 있는
단말기에서 전자화폐 카드속에 있는 현금중 쇼핑대금을 빼낸뒤 손님에게 돌려 준다.
전자화폐는 또한 카드소지자 간에 화폐가치를 이전할 수 있는지 여부에 따라
개방형 화폐와 폐쇄형 화폐로 구분하기도 한다. 몬덱스 카드가 대표적인 개방형 화폐로
전자화폐 발행기관에 통보 없이 카드소지자 간에 자유스럽게 화폐가치를 이전할 수 있는
특징이 있다. 이와 달리 벨기에서에 시범 운용되고 있는 프로톤이나 국내에서
금융결제원을 중심으로 추진중인 전자화폐는
카드소지자 간에 화폐가치 이전이 불가능한 것으로 폐쇄형 화폐에 해당한다.
이러한 전자화폐 카드는 영국, 벨기에, 네덜란드, 핀란드, 포르투칼, 스페인, 덴마크,
스위스, 미국, 캐나다, 싱가포르, 홍콩, 호주, 뉴질랜드 등에서 시험 운용되고 있다.
8.6 Millicent
Millicent는 안전하면서도 소액거래에 사용할 수 있도록 거래비용을 줄인 프로토콜로 DEC에서
제안한 소액 전자지불 시스템이다(http://www.research.digital.com/SRC/millicent/).
Millicent 전자지불 시스템은 Customer와 Vender, 그리고 Broker로 구성되며, 이들 사이에
교환되는 전자화폐 정보는 Scrip이라는 것을 사용한다. Scrip에는 브로커 Scrip과
각 Vender 고유의 Scrip이 있다.
Millicent 프로토콜은 여러가지 방법으로 트랜젝션 비용을 줄이고 있다. 먼저, Vender
Scrip의 이중사용 여부는 Vender가 직접 검사할 수 있으므로 통신의 비용을 감소시킨다.
둘째로, 거래금액이 작기 때문에 비용이 많이 드는 강한 암호기술을 사용할 필요가 없다.
셋째는, Vender Scrip 자체에 사용자의 금액정보가 들어 있으므로 Vender가 이를 관리할
팔요가 없다. 그러나 Vender가 전자서명을 통해 Scrip 내용을 인증하기 때문에
사용자는 임의로 Scrip의 금액을 변경할 수 없다.
국내에서도 전자상거래 관련 활동이 최근 본격적으로 추진되고 있다. 대표적인 국내의
관련 연구개발 동향을 살펴보면,
웹 코리아(WWW-KR) 산하 WSP(Web Security and Payments) WG에서 웹 보안기술과 전자지
불
프로토콜에 대한 연구활동이 이루어지고 있으며, 개방형컴퓨터통신연구회 산하
Internet-KIG/Secueiry WG에서는 인터넷상거래와 관련된 보안기술 연구를 수행하고
있다.
최근 WWW으로 대표되는 인터넷 서비스가 점차 상업적인 목적으로 발전해 가면서 요구되고
있는 웹 클라이언트와 서버간 인증과 부인봉쇄 서비스 및 서버 정보에 대한 접근제어
서비스, 그리고 웹 트랜젝션 정보에 대한 무결성과 기밀성 서비스를 제공하기 위한
다양한 방식들이 연구되고 있으며, 이 글에서는 이중 대표적인 몇가지 웹 보안 방안에
대해 서술하였다. 현재 우리가 사용하고 있는 대표적인 브라우저인 넷스케이프는 SSL
방식을 지원하고 있으며, 최근 발표된 마이크로소프트의 인터넷 익스플로러 3.0도 SSL
방식과 PCT 방식의 보안 프로토콜을 지원하고 있다. 특히 인터넷 익스플로러는 마스터와
비자가 합의한 전자상거래 규격인 SET(Secure Electronic Transaction)를 지원하고 있어,
WWW을 이용한 전자상거래의 가능성을 더욱 높여주고 있다.
또한 인터넷 상에서 안전한 전자상거래 서비스를 도입하기 위해 다양한 전자지불 시스템
기술이 개발되고 있으며, 각 방식별로 시범 서비스가 실시되고 있어 조만간에
인터넷을 통한 전자거래가 실용화 될 가능성이 더욱 높아지고 있으나, 기술적인 문제 뿐만
아니라 법, 제도 및 사회적 관점에서 해결되어야 할 장벽이 아직 많이 남아 있어
인터넷을 통한 본격적인 전자거래 서비스의 도입에는 다소 시간이 걸릴 것이라고 예상된다.
[1] CGI Security [http://www.primus.com/staff/paulp/cgi-security/]
5. 암호기술을 적용한 보안기법
앞에서 설명한 초기의 WWW 보안 방안들은 안전성이 취약하므로 암호학 기술을 적용한 보안
방안이 연구, 제안되고 있다. WWW에 보안기능을 제공하기 위해서 암호화 기술, 디지탈서명
기술, 키관리 기술 등의 암호학 기술이 대표적으로 사용되고 있다. 암호학 기술을 WWW에
적용하고자 할때에는 기존의 HTTP, HTML, 그리고 다른 관련 규격들을 확장시켜야 할 뿐만
아니라 이미 사용되고 있는 브라우저와 서버 프로그램을 새 버젼으로 대체해야 하는
문제가 대두된다.
또한 암호학 기술을 적용한다 해도 수많은 암호 알고리즘 및 제품이 개발되어
있어 이들 사이의 호환성 및 연동성 문제가 고려되어야 하며, 특히 암호기술의 경우
국가에
따라 법으로 기술 유출 및 사용을 제한하고 있으므로 관련 제품의 수출입과 이용에 문제가
발생할 수 있다. 이 밖에도 암호 기술을 실제 통신망 환경에서 사용하기 위해서는 인증서
발급과 증명, 키관리 등 정보보호 서비스를 제공하기 위한 기반구조가 해결되어야 한다.
이처럼 암호기술을 WWW 보안에 적용하기 위해서는 고려되어야 할 사항이 많기는
하나 향후
전자상거래 등의 다양한 응용에 WWW을 사용하기 위해서는 암호학 기술을 기반으로 하는
보안 방안이 필요하다.
암호학 기술을 적용한 대표적인 WWW 보안 메카니즘으로는 CERN에 의해 제안된 Shen,
넷스케이프사가 제안한 SSL(Secure Sockets Layer), 마이크로소프트사가 제안한
PCT(Private Communication Technology), EIT사가 제안한 Secure-HTTP,
W3C에서 개발되고 있는 SEA(Security Extension Architecture),
NCSA가 제안한 PGP/PEM-Web, 그리고 기존의 네트웍 인증시스템인 커버러스(Kerberos)를
적용한 방식 등이 있다. 이러한 보안 기법들은 HTTP 계층을 중심으로 암호기술을 어떻게
적용하느냐에 따라 다음과 같이 3가지 형태로 분류할 수 있다. 여기서는 이들 중 몇 가지
대표적인 WWW 보안기법의 특징을 살펴본다.
현재 SSL 규격 버젼.3가 작성되어 있으며, 넷스케이프와 인터넷 익스플로러와 같은
대표적인 웹 브라우저가 SSL을 지원하고 있어 사실표준으로 사용되고 있다.
넷스케이프 브라우저는 수출용과 내수용의 RC4 알고리즘의 암호키 길이를 다르게
채용하고 있는데, 각각 40비트와 128비트 이다. 40비트 암호키를 사용하는 RC4 알고리즘이
해독되어서 더 이상 안전하지 않게 되자 미국 연방정부는 수출용 버젼의 암호키 길이를
56비트로 늘이는 것을 허용했다.
특히, SSL의 경우 호주의 Eric Young에 의해 개발된 공개 소프트웨어인 SSLEAY와
SSLapps가 인터넷을 통해 무료로 배포되고 있다.
대칭키 암호 알고리즘을 사용하여 제공되며, 사용되는 비밀키는 핸드쉐이크 과정중에
교환된다.
접속 과정에서 RSA, DSS, X.509 인증서 등을 사용하여 클라이언트와 서버 인증 서비스를
제공한다.
Keyed MAC(Message Authentication Code) 기법이 사용되며 SHA, MD5 등의 해쉬함수를
사용한다.
핸드쉐이크 프로토콜을 통해 기밀성 서비스를 위한 암호 알고리즘과 암호키 등을
협상한다.
이밖에 마이크로소프트사는 SSL 규격을 일부 확장한 PCT(Private Communication
Technology)라는 규격을 발표하였으나 이는 기본적으로 SSL과 동일하다.
S-HTTP 설계시 다양한 암호화 알고리즘과 동작모드, 그리고 매개변수 들을 수용할 수
있도록 협상 메카니즘을 지원하는 것을 가장 중요하게 고려하였다.
따라서 S-HTTP는 아래와 같이 다양한 방식을 지원하며, 연결 설정시에 클라이언트와
서버간에 적절한 방식이 협상되어 선택된다.
보통의 HTTP 메세지는 요구되는 보안 기능 정도에 따라 암호화되거나 서명되어,
또는 암호화 및 서명되어 S-HTTP 메세지 내로 캡슐화 되고, 이 S-HTTP 메세지는 메세지의
형식과 부호화 방식 등을 표시해 주는 S-HTTP 헤더와 함께 전달되게 된다. S-HTTP의 동작
모델은 (그림 7)과 같다. S-HTTP와 SSL의 중요한 차이점은 S-HTTP는 SSL과는 달리 HTTP
메세지가 암호화 및 서명되어 기존 TCP/IP 망을 통해 전송된다는 것이다.
200 OK HTTP/1.0
Server: Navaho-0.1.2.3alpha
Certificate-Info : PKCS7, ......
Encryption-Identity: DN-1485,null, CN=Setec Astronomy, OU=Persona Certificate,
O="RSA Data Security, Inc.", C=US;
SHTTP-Privacy-Enhancements:recv-required=encrypt
GET /secret HTTP/1.0
Security-Scheme:S-HTTP/1.2
User-Agent:Web-O-Vision 1.2beta
Accept:*.*
Key-Assign:Inband, key-1, reply, des-ecb;7878787878787878
Secure * Secure-HTTP/1.2
Content-Transfer-Encoding: Base64
Content-Type:application/http
Content-Privacy-Domain:PKCS-7
-----BEGIN PRIVACY-ENHANCED MESSAGE -----
.......
-----END PRIVACY-ENHANCED MESSAGE -----
Secure * Secure-HTTP/1.2
Content-Transfer-Encoding: Base64
Content-Type:application/http
Prearranged-Key-Info:des-ecb,697fa820df8a6e53,inband:key-1
Content-Privacy-Domain:PKCS-7
-----BEGIN PRIVACY-ENHANCED MESSAGE -----
.......
-----END PRIVACY-ENHANCED MESSAGE -----
NCSA는S-HTTP 1.1 규격을 지원하는 Secure Mosaic과 Secure httpd를 개발하였으며,
테리사 시스템에서도 SecureWeb이라는 제품을 개발, 상용으로 판매하고 있다.
현재 S-HTTP 규격은 버젼 1.2의 세번째 수정판이 인터넷 드래프트 문서로 작성되어 있고,
RFC 문서로 채택단계를 밟기 위해 IESG에 제출되어 있는 상태이다.
SEA에서는 세가지 암호 처리 클래스 즉, 서명, 암호화, 그리고 키 교환을 정의하고 있다.
서명은 부인 불가능한 인증 서비스를, 암호화는 비밀보장 통신 서비스를, 그리고 키 교환은
암호키 정보를 안전하게 공유할 수 있는 서비스를 제공해 준다. 이 밖에도 SEA 규격에서는
사용될 인증서에 대해 규정하고 있다. 현재 SEA는 서명과 키 교환은 공개키 알고리즘에
근거하여 이루어지고, 기밀성 서비스를 위한 암호화는 세션키를 사용한 대칭키 알고리즘을
사용한다. 그리고 인증서는 X.509 인증서의 사용을 고려하고 있다. 그러나 SEA 역시
S-HTTP 처럼 협상 메카니즘을 제공하므로 다양한 암호 알고리즘을 사용할 수 있다.
W3C에서 PEP에 기반을 둔 SEA가 제안될때 많은 관심이 모아졌으나 아직 초기 상태로 이를
지원하는 업계의 움직임이 보이지 않고 있어 미래가 불투명한 편이다. 그러나 SEA는
S-HTTP와는 달리 역호환성을 제공하고, PEP에 기반을 두고 있으므로 추후에 다른 기능을
추가하고자 할때 확장성이 뛰어나다는 장점이 있다. PEP과 SEA는 현재 W3C에서 작업문서로
등록되어 있는 상태이다.
PGP/PEM-Web 보안모델은 (그림 8)과 같이 나타낼 수 있는데, WWW 클라이언트는
PGP/PEM 프로그램과 CCI(Common Client Interface), NCAPI, 또는 Plug-In 기술을 이용하여
연결됨으로써 서버와 교환되는 HTTP 메세지의 암호화 및 서명 기능을 수행한다.
현재까지는 이 방식에 따른 완전한 구현제품이 발표되지 않고 있으나 관련 연구가
국내외에서 진행되고 있다.
6. 전자상거래와 고려사항
어쨌든 인터넷에서 전자상거래의 규모가 비약적으로 성장할 것으로 예측되고 있으나,
인터넷을 이용한 상거래가 본격적으로 도입되기 위해서는 아직까지 해결되어야 할
문제점이 많이 산적해 있다.
둘째로, 판매자를 가장하여 인터넷 상에 쇼핑몰을 구축한 다음 구매자들의 신용카드
정보 등을 입수하여 이를 악용하는 것도 가능하므로 전자상거래 당사자가 서로 정당한
상대인지를 확신할 수 있어야 한다.
셋째로, 인터넷을 통한 거래는 구매자와 판매자가 서로 얼굴을 대하지 않고 거래가
이루어지므로 거래가 성립된 후에도 구매자 혹은 판매자가 거래사실을 부인할 수도
있으므로 이에 대한 대책이 필요하다.
넷째로, 전자상거래에서는 디지탈로 전송되는 거래금액 정보를 불법적으로 변조하는
경우 디지탈 정보의 특성상 이에 대한 증명이 어려우므로 이에대한 대책이 필요하다.
다섯째로, 전자화폐(Electronic Currency, Electronic Money, Digital Money)를
이용하는 전자지불 방식의 경우에 전자화폐 정보가 디지탈 데이타이므로 이를 똑같이
복제하여 사용하더라도 원래 정보와 구별할 수 없게 된다. 이와같이 전자화폐를 복제하여
두번 이상 사용하는 이중사용(Double Specding) 위협에 대한 대처가 요구된다.
여섯째로, 사용자 프라이버시 보호를 위해 전자거래에 대한 익명성이 보장되어야 하며,
이밖에도 많은 요소가 전자상거래 서비스 도입을 위해 고려되어야 한다.
7. 전자지불 시스템 개요
이러한 방식은 이용이 불편하고 대금지불 보장이 이루어지지 않으므로 보다 발전된 형태의
전자지불 방식이 연구되고 있다. 현재 연구개발 및 실용화가 이루어지고 있는 전자지불
방식에는 크게 기존의 신용카드를 이용하는 방식과 전자화폐를 이용하는 방식이 있다.
신용카드 기반의 전자지불 방식은 기존에 사용되고 있는 신용카드를 그대로 이용하여
전자거래를 하고자 하는 시도이고, 전자화폐 기반 지불방식은
은행등의 금융기관이 발행하는 전자현금이나 전자수표 등의 전자화폐를 이용하여
상거래를 하고자 하는 방식이다.
(2) 신뢰성(Reliability) : 전자지불 시스템이 제 삼자에 의한 공격, 또는 자체의 빈약한
설계에 의해서 시스템의 신뢰도가 깨진다면 큰 문제가 야기될 수 있다. 그러므로 어떠한
상황에서도 신뢰될 수 있도록 시스템이 구축되어야 한다.
(3) 확장성(Scalability) : 인터넷이 확장됨에 따라 지불 서버가 관리해야 하는
정보는 빠른 속도로 늘어날 것이다. 그러므로 적은 노력으로 시스템이 쉽게 확장
가능하여야 한다.
(4) 익명성(Anonymity) : 어떤 종류의 지불 시스템은 제삼자에 의해서 거래가 추적되는 것을
막아야 한다. 즉 거래를 통해 개인의 소비 패턴이나 개인의 수입의 원천을 알지 못하게
해야 한다.
(5) 수용성(Acceptability) : 지불 시스템의 가치여부는 그것으로 구매할 수 있는 상품에
달려 있다. 그러므로 지불 도구는 널리 받아들여 질수 있어야 하며 지불 메카니즘은
여러 서버에 의해 지원되야 한다.
(6) 고객기반(Customer base) : 지불 시스템 서버가 어떠한 지불 메카니즘을 수용할지에
대한 여부는 지불 시스템을 이용하는 사용자들의 수에 달려 있으므로, 사용자들이
사용하는데 있어서 특별한 교육이 없도록 설계해야 한다.
(7) 유연성(Flexibility) : 전자상거래 요구사항에 따라 다양한 형태의 거래 형식들이
요구될 수 있으므로 지불 서버는 이러한 것들은 모두 지원할 수 있어야 하며
여러 형태의 지불 형식은 하나의 단일한 골격에 통합되어야 한다.
(8) 변환성(Convertibility) : 사용자들은 각자의 거래에 가장 적당한 지불 구조를
선택할 수 있어야 한다. 현재 많은 지불 시스템이 있으며 각각 장단점을 가지고 있으므로
한 시스템에서 구현된 것은 다른 시스템으로 변환이 용이해야 한다.
(9) 효율성(Efficiency) : 대부분의 인터넷 거래는 소규모로 일어나므로 지불 응용은
이런 소액지불(micropayment)을 지원할 수 있어야 한다.
(10) 통합의 용이(Ease of integration) : 지불응용의 구조는 사용자들의 편의를 위해서
변경이 가능해야 한다. 통합을 위해 공통적인 API를 사용하는 것이 바람직하다.
(11) 사용의 용이(Ease of use) : 사용자들이 이용하기 쉽게 대부분의 거래는 자동적으로
일어나야 한다.
7.2.2 전자현금 기반 전자지불 시스템
전자현금 시스템은 지불시 전자현금 발급자와
온라인 방식으로 연결되어 전자지불이 이루어지는 방식과 오프라인으로
전자지불이 이루어지는 방식이 있다. 대표적인 온라인 전자현금의 시스템에는
DigiCash사의 ecash와 USC/ISI에서 개발한 NetCash가 있다. NetCash는 ecash에 비해
확장성은 좋지만 익명성이 완전하지 않다.
그리고 대표적인 오프라인 전자현금 시스템에는 IC 카드를 이용한 전자지갑형
전자현금인 몬덱스(Mondex)와 프로톤(Proton) 등이 있고, 최근 애틀란타 올림픽에서
비자가 선 보인 비자캐시(VisaCash)가 있다.
8. 주요 전자지불 시스템
iKP 프로토콜에의 참여자는 Buyer, Seller, Issuer, 그리고
Acquirer가 있으며, 이들로 구성되는 전자지불 시스템의 기본모델은 그림 10과 같다.
여기서, Acquirer가 속하는 기존 금융시스템과 Seller 사이의 인터페이스를 위해
Acquirer Gateway가 요구될 수 있다.
+-------+ +--------+ +----------+
| Buyer | | Seller | | Acquirer |
+-------+ +--------+ +----------+
1. INITIATE
--------------------->
2. INVOICE
<---------------------
3. PAYMENT
<---------------------
CANCEL(optional)
--------------------->
4. AUTH-REQUEST
--------------------->
5. AUTH-RESPONSE
<---------------------
6. CONFIRM
<---------------------
Goods and Services
<---------------------
7. CLEAR-REQUEST
--------------------->
8. CLEAR-RESPONSE
<---------------------
A. INQUIRY
--------------------->
B. STATUS
<---------------------
현재 3가지 프로토콜이 1KP, 2KP, 3KP로 정의되어 있다. 여기서 i는 자신의 공개키 쌍을
소유하고 있는 구성요소의 갯수를 의미한다. 즉, 1KP는 가장 간단한 프로토콜로
Acquirer Gateway만이 공개키 쌍을 소유하며, Buyer와 Seller는 Gateway의 공개키 또는
Gateway의 공개키를 확인해 줄 수 있는 인증기관의 공개키 만을 알면 된다.
이러한 모델에서 비자나 마스터카드와 같은 신용카드 회사가 Acquirer Gateway 역할을
하면서 공개키 인증등을 해 주는 형태의 시스템 구축이 가능하다. 1KP는 간단하지만
Buyer와 Seller 사이에 송수신되는 메세지 부인봉쇄 서비스를 제공하지는 않는다.
2KP는 Acquirer Gateway 뿐만 아니라 Seller도 자신의 공개키 쌍을 소유한다. 따라서
Seller가 전송하는 메세지에 대한 부인봉쇄 서비스가 제공된다. 그리고 Buyer는
Seller의 인증서를 확인함으로써 제3자에게 온라인으로 확인하는 절차 없이
정당한 쇼핑몰인지를 확인할 수 있게 된다.
3KP는 Buyer도 자신의 공개키 쌍을 소유하는 형태로 모든 메세지에 대한 부인봉쇄 서비스가
재공된다. 따라서 구매자가 자신의 구매요구 및 지불에 대한 서명을 하게 되므로
거짓구매나 지불에 대한 부인이 불가능하게 되며, 이러한 모델에서는 고객들의 공개키
관리를 위한 키관리 기반구조가 요구된다.
SET는 응용계층 프로토콜로 기본적으로 iKP와 유사한 프로토콜이라고 할 수 있다.
SET 구성요소로는 Cardholder, Merchant, Acquirer가 있고, 시스템 구현상 Acquirer
Payment Gateway, Certification Authority, 그리고 Issuer 등이 요구될 수 있으며,
전체 시스템 구조는 그림 11와 같이 나타낼 수 있다.
SET에서는 보안기능을 제공하기 위해 RSA, DES, SHA-1등의 암호기술을 사용하며,
또한 공개키 인증을 위해 X.509 Ver.3 확인서를 사용하고 있다.
아직까지 SET에서 정의된 모든 요구사항을 지원하는 구현제품이 개발되지는 않았지만
VeriFone사에서는 SET에 따라 Merchant와 Acquirer 간의 지불 트랜젝션을 구현한
제품을 최근 발표하였다(http://icd.verifone.com/). VeriFone이 구현한 제품의
메세지 흐름은 그림 13와 같다.
여기서 EPO(Electronic Payment Order)는 구매하는 상품식별자, 가격, 암호화 검사합값,
Timeout Stamp등으로 구성되는 정보이다. 암호화 검사합값은 MD5등과 같은 암호
알고리즘을 사용하여 생성되는 정보로 메세지에 대한 무결성을 보장하기 위한 것이다.
Invoice는 가격정보와 검사합값, 상품에 대한 복호키 등으로 이루어진다.
그리고 단계7에서 서버는 EPO를 검사하여 구매자의 계좌에 돈이 있거나 신용이 있는
상태이면 Merchant에게 Customer의 돈을 이체시키고, 이러한 트랜젝션 정보와
복호키 값을 저장해 놓는다. NetBill 시스템에서는 Custumer에서 전자지불 기능을
수행하는 모듈을 Check Book이라고 부르며, Merchant측에 있는 모듈을 till이라고
정의하고 있다.
따라서 전자화폐에서도 기존 현금과 마찬가지로 익명성을 가능하게 하는 기술이
요구되는데, DigiCash사의 David Chaum이 고안한 블라인드 서명(Blind Signature) 기법은
전자현금의 익명성을 보장하게 해 준다. 블라인드 서명의 기본 개념은 사용자가 은행에
인출할 현금에 대한 일련번호를 제공할 때 일련번호에 난수를 곱하여 은행에 전달하면
은행은 이 번호를 전자현금화 해서 전자현금 발행요구자에게 주게 된다. (이때 사용자가
만드는 일련번호값을 충분히 크게 함으로써 다른 사람이 발행하고자 하는 전자화폐와
같은 일련번호가 발생하지 않도록 해야 하며 보통 100자리 이진수면 이를 보장한다.)
사용자는 은행으로 부터 받은 전자현금 정보를 자신만이 알고 있는 최초의 난수값으로
다시 나누어 원래 일련번호를 갖는 전자현금으로 환원하여 사용하는 방식이다.
이렇게 함으로써 은행은 사용자가 인출해 간 전자현금 번호를 알 수 없게 되므로
전자현금에 대한 익명성이 보장되게 된다.
또 다른 중요한 전자화폐에 대한 요구사항은 이중사용의 방지이다. 이중사용을
방지할 수 있는 가장 쉬운 방법은 전자화폐를 발행한 은행이 데이타베이스를 구축하여
발행된 전자화폐의 일련번호를 관리하고 있다가, 전자화폐에 대한 유효성을 문의해 오면
사용된 화폐인지를 확인하여 알려 주는 방식이다.
이런 방식은 온라인으로 전자화폐의 유효성을 확인해 주어야 하므로 통신 정보량이
증가하고 확장성이 떨어지게 된다. 최근에는 전자화폐를 발행할 때 특별한 방식으로
만듬으로써 전자화폐의 이중사용 유무를 확인하기 위해 온라인으로 은행에 접속할 필요
없이 수학적으로 이를 확인하는 방식이 연구 제안되고 있다.
ecash 시스템에서 구매 및 전자지불이 일어나는 과정은 그림 15와 같다.
단계4에서 전자현금은 Merchant 만이 복호할 수 있도록 Merchant의 공개키로 암호화
하여 전송된다. 단계5에서 Merchant는 Buyer가 보내 온 전자현금을 자신의 비밀키로
서명하고, 이를 다시 은행의 공개키로 암호화 하여 은행에 전송한다.
은행은 Merchant가 보내 온 전자현금 정보의 이중사용 유무를 검사하여 전자현금이
유효하면 이를 Merchant의 계좌에 입금시키고, 사용된 전자현금으로 데이타베이스에
등록한다. 단계6에서 은행으로 부터 전자현금에 대한 처리결과를 통보 받으면
Merchant는 Buyer의 Cyberwallet에 서명된 영수증을 발급한다.
전자화폐 카드는 돈을 미리 주고 구입하는 선불카드(Prepaid Card)와 비슷하다.
그러나 중요한 차이점은 전자화폐 카드는 은행에 있는 자신의 계좌로 부터 전자현금을
필요할 때 마다 자신의 카드로 이체시켜 사용할 수 있다는 것이다. 즉, 카드 보유자는
카드에 저장되어 있는 전자현금이 떨어지면 은행의 전자화폐 카드용 ATM 단말을 통해
자신의 은행계좌로 부터 전자현금을 충전할 수 있으며 이체받아 카드에 저장한 다음
다시 사용할 수 있다.
전자화폐 카드의 한 형태로 지난 애틀란타 올림픽에서 사용된 것이 비자캐시(VisaCash)
이다(http://www.visa.com/cgi-bin/vee/sf/cashmain.html).
비자캐시가 몬덱스와 다른점은 몬덱스는 카드소지자가 자신의 은행계좌로
부터 직접 전자현금을 자기의 IC 카드로 옮기는 데 반해, 비자캐시는 신용카드 회사인
비자가 카드소지자에게 일정금액을 카드에 융자해 주는 것으로 융자된 금액은
추후 카드소지자의 지정된 은행 계좌에서 카드 회사로 인출되게 된다.
Millicent 프로토콜의 기본 개념을 살펴보면 먼저, Customer는 브로커로 부터 브로커
Scrip을 사서 가지고 있다가, 이 브로커 Scrip을 가지고 원하는 Vender의 Scrip을 산다.
브로커는 Vender들로 부터 Scrip을 대량 구매하여 가지고 있다가 요청하는 Customer에게
자신의 브로커 Scrip을 받고 팔게 된다.
Customer는 Vender에게서 물건을 주문한 후 Vender Scrip을 지불하면, Vender는
해당 금액을 제한 나머지 금액을 Vender Scrip에 표시하여 Customer에게 돌려준다.
Customer는 나중에 이 Vender Scrip을 다시 사용할 수 있다.
9. 국내외 전자지불 기술 현황
지금까지 언급된 여러 형태의 전자지불 시스템에 대한 연구개발 및 실용화 노력이
전세계적으로 활발하게 추진되고 있다. 이중 중요한 몇가지 움직임을 살펴보면
먼저, 비자와 마스터카드와 같은 신용카드를 중심으로 추진되고 있는 신용카드
기반의 전자지불 시스템의 실용화 노력이다. 특히, 비자와 마스터카드가 공동 규격으로
합의한 SET가 인터넷에서 신용카드 기반의 전자지불 시스템 표준으로 자리를 잡아가고
있는 분위기 이며, 이를 지원하는 제품이 개발되고 있다.
다음으로 주목할 만한 움직임은 최근 IC 카드 기반의 전자지갑형 전자현금 시스템
도입의 급속한 확산이다. 영국의 몬덱스, 벨기에의 프로톤, 비자에서 개발한 비자캐시 등이
대표적이며, 이밖에 세계의 여러 국가에서 경쟁적으로 IC 카드 기반의 전자지갑 서비스를
도입하는 추세이다. 특히 비자와 마스터카드, 그리고 유로피는 신용카드를 IC 카드화
하기 위한 통일 카드사양인 EMV(Europay, Master and Visa) 규격을 '95년 6월에
만들었으며, 향후 5년내에 지금의 자기카드를 모두 IC 카드로 대체하겠다는 계획을
가지고 있다. 이는 전자지갑형 전자현금 서비스가 더욱 급속하게 도입될 수 있는
가능성을 제공한다.
이러한 전자지불 시스템은 기업, 백화점, 은행, 카드회사 등 전자상거래 관련 기관들이
연계되어야 하며, 서비스 확장을 위해서는 표준방식의 개발이 중요하다. 따라서
여러 관련 기관들이 공동으로 컨소시엄을 구성하여 전자지불 시스템을 개발하고,
시범사업을 추진하는 움직임이 활발하다. 특히, 유럽은 EC 통합을 앞두고 EC 역내
국가들 간에 전자지불 시스템 개발을 위한 공동 프로젝트를 추진중에 있는데 대표적인
것으로 CAFE(Conditional Access fro Europe), SEMPER(Secure Electronic Marcketplace
for Europe) 등이 있다.
CAFE는 1992년 부터 1995년 까지 EC ESPRIT 프로그램으로
유럽의 13개 기관이 연합으로 참여한 전자지불 기술개발 계획을 말한다.
CAFE는 소액 및 고액 전자지불, 신용카드와 같은 Post-Pay, 그리고 선불카드 개념의
부가가치 저장 카드와 같은 Pre-Pay 등을 위한 개방형 전자지불 구조를 개발하고
시범운용을 하고 있다.
SEMPER는 1995년 9월에 시작된 EC의 ACTS 프로젝트로써 인터넷 및 다른 공중망을 통해
안전한 전자상거래를 실현하기 위한 해결책을 개발하는 것을 목표로 하고 있다.
현재, 이 컨소시엄에는 유럽의 18개 기관이 참여하고 있으며 IBM Zurich Research
Lab이 총괄하고 있다.
데이콤은 국내 11개 시중은행과 인터넷 쇼핑몰을 데이콤의 지불서버와 전용선으로
연결해 이용자들이 편리하게 대금을 결제할 수 있도록 중개하는 서비스를 추진하고 있다.
금융결제연구원에서 추진중인 전자지갑형 전자화폐 표준 개발작업도 거의 완료단계에
이른 상태이다. 또한 여러 시중은행에서도 전자지갑 시험서비스를 추진하고 있으며,
서울시와 부산시, 철도청 등에서도 선불형 전자화폐 카드를 도입하고 있다.
최근에는 본격적인 전자상거래를 지원할 수 있는 전자화폐를 체계적으로 연구하고,
전자상거래에 대한 전략적 대응방안을 모색하기 위해 산.학.연.관 전문가로 구성된
전자화폐연구회가 조직되었다.
전자화폐연구회의 주요 연구분야는 전자화폐를 둘러싼 국내외 현황과 동향을
분석하고, 국내도입에 적합한 전자화폐의 형태, 전자화폐 관련기술 및 표준화연구를
수행할 예정이다. 또한 통화정책, 금융제도 등이 경제에 미치는 파급효과와 전자화폐
관련 국제협력 방안, 전자화폐 도입을 위한 시범 프로젝트 등을 추진해 나갈 예정이다.
전자화폐연구회는 우선 정보통신진흥협회 내 전자상거래협의회 산하 연구회로 활동하며,
앞으로 각계 각층의 참여를 유도하여 별도의 전자화폐연구조합으로 발전해 나갈
계획이다.
또 다른 움직임으로는 한국과학기술원 인터넷상거래연구실과 다수의 기관들이 컨소시움
형태로 전자상거래의 공동연구를 수행하기 위한 국제상거래연구센터(ICEC: International
Center for Electronic Commerce)의 설립설명회를 최근 개최하였다. ICEC는 인터넷을
이용한 전자상거래 기술과 경영기법의 연구, 관련 자료 수집 및 교류, 출자 및 참여기업에
기술전수, 관련 법률 및 제도 개선안 건의 등을 활동방향으로 하고 있다.
이와 함께 메타랜드라는 전자상거래 서비스를 구현할 주식회사를 설립할 예정인데,
메타랜드는 백화점, 은행, 신용카드, 광고, 예약, IC카드 기반 전자화폐 등을
연계시키는 종합 전자상거래 서비스 체계의 구현을 추진할 예정이다.
현재 국내에서 운용되고 있는 인터넷 쇼핑몰로는 롯데
사이버쇼핑몰(http://cyber.shopping.co.kr/),
데이콤 인터파크(http://www.interpark.com/shop/home.html) 등이 대표적이다.
10. 결 론
제안된 여러 웹 보안방식중 어느 방식이 앞으로 웹의 표준 보안 프로토콜로 사용될 지는
아직 미지수 이지만 지금까지의 분위기로는 S-HTTP와 SSL, 그리고 SEA/PEP 방식이
비교적 주목을 받고 있는 편이다. 그렇지만 넷스케이프와 모자익, 그리고 인터넷
익스플로러와 같은 대표적인 브라우저와 웹 서버가 어느 방식을 지원할 것인지가
무엇보다도 중요한 변수일 것이다.
국내의 경우 현재 대부분의 웹 시스템 및 도구를 외국제품에 의존하고 있는 상황이다.
그러나 보안의 특수성에 비추어 볼때 외국의 보안제품 및 기술을 그대로 국내에 적용하여
사용하기에는 여러가지 문제가 있다. 적어도 보안 알고리즘은 국내 사정에 맞는 방식을
개발하여 이를 사용할 수 있어야 할 것이며, 이를 위해서는 표준 웹 보안 방식을 지원하는
제품을 자체적으로 구현, 사용할 수 있도록 연구개발에 힘을 쏟아야 할 것이다.
또한 최근, IC 카드 기반의 전자지갑형 전자현금에 대해 많은 금융기관이 관심을 갖고
있으나 아직까지 본격적으로 확산되고 있지는 않다. 그 이유로는 먼저 이러한 새로운
형태의 금융서비스가 해커 등으로 부터 정말 기술적으로 안전한 것인지에 대한 의문이
적지않다. 그리고 전자현금의 발행기관을 은행으로만 제한하고, 발행금액도 일정 규모
이내로 제한함으로써 적절한 감독과 규제가 필요하다고 주장하고 있다. 이는 공신력이
없는 기관이 전자현금을 발급하게 될 경우 문제가 발생시 사회적 혼란이 일어날 수도
있음을 우려하는 시각에서 이다.
하여튼 IC카드 기반의 전자지갑이 가장 빨리 실용화될 수 있을 것으로 예상되기는 하지만
본격 도입에 앞서 이러한 새로운 금융서비스의 도입에 따라 파생될 수 있는 제반 문제점을
충분히 검토하여 신중하게 대처해야 할 것이다. 그중에서도 가장 중요하게 국가적으로
관심을 가지고 고려해야 할 부분은 바로 안전한 전자상거래를 가능하게 하는 핵심
기반기술인 보안기술에 대한 연구 개발일 것이다.
참고문헌(References)
[2] NCSA httpd: Setup More Secure
[http://hoohoo.ncsa.uiuc.edu/docs/tutorials/security.html]
[3] Writing Secure CGI Scripts(NCSA)
[http://hoohoo.ncsa.uiuc.edu/cgi/security.html]
[4] SSL Protocol [http://cgi.netscape.com/eng/ssl3/index.html]
[5] Secure Mosaic [http://www.comerce.net/software/Smosaic/]
[6] Secure HTTPd [http://www.comerce.net/software/Shttpd/]
[7] Terisa Systems Home Page [http://www.terisa.com/]
[8] E.Rescorla, A.Schiffman, S-HTTP Specification Ver.1.2,
draft-ietf-wts-shttp-02.txt, May 1996.
[9] Judson D. Weeks, et al. etc., CCI-Based Web Security: A Design Using PGP,
4th WWW Conference.
[10] Rohit Khare, SEA, WD-http-sea, W3C, Jan. 1996.
[11] Rohit Khare, PEP, WD-http-pep, W3C, Aug. 1996.
[12] Adam Cain, Web Security, 5th WWW Conference, Tutorial Notes, May 1996.
[13] 강신각, WWW 보안, NETSEC-KR'96, 1996.5
[14] Requirements for Web Transaction Security, draft-ietf-wts-requirements-01.txt
[15] Michael Peirce, et al., Scalable, Secure Cash payment for WWW Resources
with the PAYME Protocol Set, 4th WWW Conference, Dec. 1995
[16] Steve Glassman, et al., The Millicent Protocol for Inexpensive Electronic
Commerce, 4th WWW Conference, Dec. 1995
[17] B. Clifford Neuman, et al., Requirements for Network Payment: The NetCheque
Perspective, IEEE COMPCON'95, March 1995.