WWW보안과 전자화폐

권도균
대전 광역시 유성구 가정동 34
데이콤연구소 전자지불프로토콜연구팀
E-mail : dgguen@madang.dacom.co.kr
URL : http://madang.dacom.co.kr/~dgguen/
Abstract:
네트웍상의 정보를 보호하기위한 암호화(Cryptography)시스템의 개요와 관련된 표준을 소개하고, WWW보안 프로토콜로 제안된 S-HTTP와 SSL을 소개, 비교한다. 그리고 이미 개발된 다른 WWW보안 시스템들을 소개하고 상호 비교한다.
현제 네트웍을 기반으로한 전자거래에 있어서 핵심적인 문제로 부각된 전자화폐, 전자지불시스템의 원리와 제안된 여러가지 프로토콜과 관련된 기업들을 소개/비교하고 전자화폐의 향후 전망과 한국적전자화폐/전자지불 시스템의 방향을 제안한다.
Keywords:
Cryptography, WWW, Security, Payment, Cash , 암호학, 보안, 전자지불, 전자화폐

1. 인터넷 전자상거래의 유형

인터넷은 정보의 바다라고 불리운다. 수백만대의 호스트들가운데 많은 호스트들에 운영되는 Anonymous FTP, 고퍼, WWW서버들을 잘만 뒤지면 1년동안 일해서 얻어야하는 프로젝트의 산출물을 친절한(물론 영어로 되어있겠지만) 문서와 프로그램 소스까지 구할수도 있는 것은 사실이다. 그래서 사람들이 인터넷을 좋아하는 것일지도 모른다. 그러나 최근 수년간 인터넷 네트웍접속서비스가 상용화되면서 인터넷의 인구가 3000만을 넘자 인터넷을 상업적인 시장으로 보려는 시각이 일어났다. 대표적인 선두주자는 역시 장사에 이력이 나 있는 미국이었다. 미국은 백악관에서 발벗고 인터넷을 상업적으로 이용하겠다는 소위 "초고속 정보통신망"이야기를 꺼내어들고 나왔다. 세계 여러나라에서도 인터넷을 활용하려는 붐이 일어났다. 물론 한국에서도 마찬가지이다. 그러던 중 넷스케이프(Netscape)와 같은 인터넷상의 신생회사가 급성장하는등 인터넷의 붐이 일고 있다. 이런 열풍은 컴퓨터업계의 황제인 마이크로소프트마져 휘청거리게 만들고 있다.
전자상거래(Electronic Commerce)라는 이름이 SF소설속의 용어가 아니라 바로 눈앞에 다가 온 듯하다. 기업들마다 인터넷에 호스트를 접속하고 홈페이지를 만들고 있다. 좀더 앞서간 기업들은 인터넷을 유통의 장으로 이용하거나, 인터넷을 통한 광고수익을 짭잘하게 올리는 기업도 있고, 본격적인 쇼핑몰을 구축하기도 한다.

인터넷 전자상거래의 유형들

2. 인터넷 비즈니스의 걸림돌 - Payment

인터넷상의 비즈니스, 전자상거래가 활성화되기위해서는 선결해야 하는 여러가지 걸림돌들을 제거해야한다. 네트웍접속, 소프트웨어/하드웨어 플랫폼, 물품의 배달, 멀티미디어 정보, 지불방식, 법률적 제약등 해결해야 하는 문제가 많다. 그럼에도 불구하고 현재 인터넷상에는 비즈니스를 성공적으로 이끌어가는 기업들이 있다.
이런 여러가지 문제점들가운데 아킬레스 건과같은 문제는 바로 지불방식이다. 돈을 주고 받는 메커니즘이 명확히 제시되지 않으면 전자 상거래의 기본이 흔들리기때문이다. 현재 성공적으로 비즈니스를 이끌어가는 인터넷 전자상거래기업들은 이런 문제를 회피하고 있긴하지만 본격적인 인터넷 전자상거래가 활성화되면 지불문제가 중요한 문제로 부각될 것이다.

그러나 현재 인터넷상에서 일반적으로 사용되는 지불방식과 문제점은 다음과같다.

이외에도 공통적으로

3. WWW 보안(Security)

3.1 시스템보안(System Security)과 자료보안(Data Security)

3.1.1 시스팀보안(System Security)
시스팀 보안이란 컴퓨터시스팀의 O.S. 응용프로그램, 서버등의 보안허점을 이용해 해커들이 침입해서 컴퓨터시스팀을 이용하는 것을 방지하는 것을 말한다.
특히 WWW서버에서는 (1) CGI프로그램과 관련된 부분과 (2) 디렉토리리스팅을 보여주는 것등이 주의를 요하는 부분이다. 특히 WWW서버를 Access한 로그파일에는 URL의 전부가 보여지므로 URL에 사용자명과 패스워드를 넣어서 사용할경우, 그대로 로그에 남으니까 주의를 해야한다.

3.1.2 자료보안(Data Security)
자료보안은 컴퓨터시스팀이 아니라 그속에 들어있는 정보자료를 보호하는 것을 말한다. 특히 네트웍환경에서 정보를 전달할때는 중간에 가로채거나, 수정하거나하는 해킹을 당할수 있는데, 이런 위험으로부터 정보를 안전하게 신뢰할수 있게 전달하는 것을 목표로한다. 여기에는 주로 암호화, 전자서명등의 방식이 이용된다.

3.1.3 Security Attacks
자료 보안을 깨트리는 시도(Attack)는 크게 네가지로 구분해 볼수 있다.
  • 가로막기 (Interruption )
  • 가로채기 (Interception)
  • 수정 (Modification)
  • 위조 (Fabrication)

3.2 암호화(Cryptography) 방법

3.2.1 Encryption
암호화(Encryption)은 자료의 기밀성(Confidentiality)를 보장하는 방법이다. 암호화는 일반적으로 원래의 자료(Message)와 그 것을 암호화하는 키(Ke)와 암호화된 자료(Crypted Message)와 그 암호화된 자료를 원래의 자료로 복원 시키는 키(Kd)등으로 구성된다.

  • Symmetric Cryptography
    대칭형 암호화방식은 자료를 암호화하는 키와 암호화된 자료를 복호화하는 키이가 동일한 암호화방식이다. 일반적으로 많이 사용되고 알려진 암호화방 식이다.
    이 방식의 장점은
    1. 암호화와 복호화가 빠르다는 점
    2. 여러가지 다양한 암호화 기법이 개발되어있다.

    이 방식의 단점은

    1. 복수의 사용자가 동일한 자료를 사용할때 키의 공유문제가 발생한다.

  • Asymmetric Cryptography
    비 대칭형 암호화방식은 암호화정보를 네트웍상의 상대편에게 보낼때 키까지 보내야하는데, 그 키를 보호할 길이 없다는 문제의식에서 개발되기 시작했다. 1970년대부터 "Secure Communication over Insecure Channel"이라는 주제의 문제의식에서 연구가 활발히 진행되었고 그 결과 비대칭형(공개키)암호화 방법들이 나오게 되었다.
    인터넷에서 공개키 암호화방식이 중요하게 대두되는 이유는 TCP/IP프로토콜을 사용하는 인터넷이 Secure한 Channel이라고 보지 않기때문이다.

    비대칭형 암호화방식으로는

    1. Diffie-Hellman Key Exchange메카니즘
      Diffie-Hellman 메커니즘은 1976년 Stanford대학의 Whitfield Diffid와 Martin Hellman가 발표한 논문에 의해 만들어졌다. 처음에 이 두사람은 Public Key암호화방식을 의도했으나 실제로 이 방식은 암호화방식이라기 보다는 키를 안전하게 전달하는 방법이었다.
      이 방식은 고전적인 Public Key암호화방식으로 취급되지만, 아직까지도 임시키를 교환하는 메커니즘에 많이 사용되고 있다.

    2. RSA
      RSA는 1977년 MIT의 세 젊은 교수 Ronald Rivest, Adi Shamir, Len Adleman 세 사람에 의해 만들어진 Public Key암호화 방식이다.

      RSA의 원리를 살펴보자.

      1. 철수의 Public키/Private키 생성 - 철수는 두개의 (큰) 솟수를 취한다 : 47, 71 - 두 솟수를 곱해서 N을 구한다. : 47 * 71 = 3337 - (47-1)*(71-1)=3220값과 관련이 없는 새로운 솟수를 선택 : 79 - Public키 : N=3337, e=79 - Private키 : N=3337, d = (79(-1승))(mod 3220) = 1019 2. 영희가 철수에게 비밀편지를 보내는데 철수의 Public키로 암호화한다. - (비밀편지(688) 를 79승하고) mod 3337 = 1570 - 이(1570)를 철수에게 보낸다. 3. 철수가 영희의 비밀편지를 자신의 Private키로 해독한다. - (1570을 1019승하고) mod 3337하면 688을 얻는다.
    3. LUC
      LUC는 1993년 뉴질랜드에서 만들어진 새로운 public Key암호화방식이다. LUC는 lucas sequence가운데 큰 정수를 이용해 public키와 Private키를 생성하는 방식으로 RSA보다 효율이 더 좋은 암호화방식으로 알려졌다.
    등이 있다.

3.2.2 Message Authetication와 Digital Signature
암호화를 통해서는 정보의 기밀성(Confidentiality)을 지킬수는 있지만, 이 메시지가 정말 내가 기대했던 그 사람이 보낸 것인지, 또 내용의 수정이 없는 것인지에 대한 보증은 할 수는 없다. 그래서 Authetication과 전자서명기법 으로 이를 보완한다.

Message Authetication은 메시지를 송수신하는 측외의 제 3자가 이를 수정하는 것을 방지하는 측에 촛점이 맞추어져 있으며

  1. 메시지가 수정되지 않았는지,
  2. 메시지의 순서가 바뀌지 않았는지
에 대한 보증을 하는 메커니즘이다.

Authetication방식에는 다음 세가지 방식이 있다.

  • Message Encryption by Public Key Method
    메시지를 자신의 Private키로 암호화해서 수신측에 보내면 수신측에서는 보낸사람의 Public 키로 메시지를 복호한다. 상대편의 Public키로 메시지가 복호된다는 것은 이 메시지가 그 사람의 Private키이로 암호화가 된 것이라는 증명이되고 Private키를 아는 사람은 상대편이기때문에 이 메시지가 정말 내가 기대하던 그 상대편이 보낸것이라는 사실을 확인할 수 있는 것이다.
    이것이 바로 전자서명(Digital Signature)의 기능을 하는 것이다.

    그러나 여기에는 몇가지 단점이 있다.

    1. Public Key암호화방식으로 메시지를 암호화하는 것은 속도가 너무 느리다.
    2. Confidetiality가 보장이 되지 않는다. 즉 송신자의 Public키는 누구나 알수 있는 정보이므로 메시지를 누구나 해득할수 있다.
      이를 해결하기위해 자신의 private키로 암호화하고 수신자의 Public키로 다시 재 암호화해서 보냄으로 Authetication, Signature, Confidetiality를 함께 보증하기도 한다.

  • Cryptographic Checksum (MAC: Message Authentication Code)
    메시지를 주고받는 두 측이 동일한 키들을 가지고 있다면, 송신측에서는 메시지의 Checksum을 구한후(MAC) 그 내용을 암호화해서 메시지에 붙여서 보내고 수신측은 그 값을 해독해서 메시지의 Chechsum을 새로이 계산해서 동일하면 메시지가 변경이 없었음을 증명하는 방식이다.

  • Hash Function Checksum대신 Oneway Hash함수를 이용해 MAC데이타(Message Digest)를 생성하는 방식이다. 최근 많이 사용되는 방식이다.

    많이 사용하는 Hash알고리즘으로는

    1. MD2
    2. MD4
    3. MD5
    등이 있다.

Digital Signature는 메시지를 송수신하는 당사자간에 상호 메시지의 신빙성여부 에 대한 보증을 하도록 하는데 촛점이 맞추어져 있으며,

  1. 수신자측에서는 이 메시지가 정말 기대했던 송신자가 보낸것인지를 확인 할수 있게 하고,
  2. 송신자는 자신이 서명한 메시지를 부인하지 못하도록 하며,
  3. 수신자가 부당한 메시지를 생성해서 송신자가 보낸것이라고 주장할수 없도록하는
기능이 있다.

전자서명(Digital Signature)은 일반적으로 Public키 암호화방식을 이용해서 이루어진다. 전송되는 메시지의 특정 데이타를 자신의 Private키로 암호화해서 (서명해서) 수신측에 보내면 수신측은 송신측의 Public키로 복호를 해서 정상적으로 메시지가 해독되면 정말 이 메시지는 송신자가 보냈다는 사실을 증명할 수도 있고, 또 송신자는 자신이 이 메시지를 보냈다는(서명했다는) 사실을 부인할 수 없게 된다.

3.2.3 Authetication System
Authetcation을 위한 전문적인 시스팀으로는 대표적인 것이 다음과 같다.

  • Kerberos
  • X.509

3.2.4 보안 응용시스팀(Security Application)
정보보안을 위해 만들어진 응용시스팀들은 다음과 같다. 주로 메일/디렉토리서비스/ WWW/네트웍관리등과 관련된 시스팀들이다.

  • PGP - 메일
  • PEM - 메일, IETF표준
  • Kerberos - Authetication
  • SNMP v2 - 네트웍 관리
  • S-HTTP - WWW
  • SSL - Transport Layer Security

3.3 일반적인 WWW보안 메커니즘

3.3.1 IP Address Authetication
서버를 설치할때 서버의 정보를 Access할수 있는 브라우져의 IP주소 혹은 도메인을 지정해서 설치할수 있다. 이렇게하면 등록된 IP주소 혹은 도메인이 아니면 해당정보를 접근할수 없게 된다.

사용예1 (NCSA서버) - access.conf파일 <Limit GET> order allow,deny allow from 164.124.* deny from 164.124.1.* </Limit> 사용예2 (CREN서버) # # Protection setup by hosts; you can use both domain name # templates and IP number templates # Protection PROT-SETUP-HOSTS { UserId nobody GroupId nogroup ServerId YourServersFancyName AuthType Basic PasswdFile /where/ever/passwd GroupFile /where/ever/group GET-Mask @(*.cern.ch, 128.141.*.*, *.ncsa.uiuc.edu) } Protect /very/secret/URL/* PROT-SETUP-USERS Protect /another/secret/URL/* PROT-SETUP-HOSTS

3.3.2 Basic Authetication
Basic Authentication은 HTTP 1.0사양으로서 대부분의 브라우져와 서버에서 채용 구현되어있는 사양으로서 "사용자명/패스워드"를 관리할 수 있도록한다.
이 방식은 IP Address Authetication과 함께 섞어서 사용하기도 한다
이방법이 동작하는 메커니즘은 그림과 같다.

이 방법은 간단하다는 장점이 있다. 그러나 사용자에서 서버측으로 전달되는 사용자명과 패스워드는 암호화가 되지 않는다. 즉 처음에 논의된 가로채기등이 가능한 곳 에서는 보호받을 수 없다. 또한 서버가 거대하고 복잡한 디렉토리구조로 되어있고 거기에 따라 허용될 사용자의 그룹이 서로 다르고 복잡하게 연결되어있으면 운영히기가 여간 힘들 지 않다. 또한 결과로 넘어가는 url에 대응된 문서는 보호받지 못한다. 그러므로 Basic Authetication외에 좀더 강력한 보안프로토콜이 필요하다.

실제로 서버에서 설치하는 것은

  1. NCSA서버
    원하는 디렉토리에 ".htaccess"파일을 만들고 여기에 접근가능한 사용자들과 패스워드파일을 지정한다. 
    
사용예 : 

AuthUserFile /otherdir/.htpasswd
AuthGroupFile /dev/null
AuthName ByPassword
AuthType Basic
	

require user pumpkin
  2. CERN서버
    • 해당 디렉토리에 ".www_acl"파일을 만들고 파일단위의 접근제어를 할수 있다.
    • configulation파일에 Protection지정에 GetMask로 디렉토리단위 접근제어를 할수 있다.
    사용예 : Access Control List File(.www_acl) secret*.html : GET,POST : trusted_people minutes*.html: GET,POST : secretaries *.html : GET : willy,kenny

3.3.3 Message Digest Authetication
Basic Authetication에서는 패스워드를 거의 암호화없이(Uuencode만으로) 서버에게 전달된다. 그래서 네트웍상에서 전송되는 패스워드를 가로채기를 하면, Uudecode만하면 패스워드를 쉽게 알수있다.

이런 약점을 보완하자는 생각에서 패스워드를 OneWay Hash(MD5)로 encoding해서 서버에게 전달함으로써 네트웍상에서 이 정보를 가로채더라도 이 정보를 가지고 패스워드를 해석할수 없도록 하는 매커니즘이다. 이방법이 동작하는 메커니즘은 그림과 같다.
서버측에서도 로긴명/패스워드등의 정보를 MD5로 인코딩해서 저장한다.
관련 드래프트는 ftp://ftp.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-http-digest-aa-02.txt에 있다.

3.4 S-HTTP

S-HTTP는 EIT(Enterprise Integration Technologies)에서 제안한 HTTP의 Security확장판이다. 프로토콜은 HTTP세션으로 주고받는 자료를 암호화,전자서명 등을 지원하는 메커니즘이다. 현재 1.1버젼의 draft가 http://www.commerce.net/information/standards/drafts/shttp.txt에 나와있다.
S-HTTP는 HTTP를 캡슐화하면서도 HTTP와 같은 message base 프로토콜이다. 또한 HTTP처럼 요청(request)과 응답(response) 구조를 그대로 이용하고있다.

3.4.1 S-HTTP시스팀 디자인 목표
  1. Enable Spontaneous Commercial Transactions
  2. Negotiation of Algorithms, Modes & Parameters
  3. Layer separation (Don't "Fix" HTTP)
  4. Mechanism, not Policy
    • Trust Model Independence
    • Where do Certificates Come From?
    • What Do Certificates Mean?
  5. Interoperability
    • With Existing Clients & Servers (w/o Security)
    • With Implementations of Varying Capabilities
3.4.2 암호화메커니즘
  1. Encapsulation Format: PKCS-7, PEM or PGP
  2. Signature Algorithm: RSA or DSA
  3. Key Exchange Algorithm: RSA, In-band, "Outband", D-H, Kerberos
  4. Message Digest Algorithm: MD2, MD5 or SHA
  5. Encryption Algorithms: DES, DES-EDE2/EDE3, DESX, IDEA, RC2, RC4
  6. Protection Mode: Signature, Encryption, Keyed MAC
  7. Public Key Certificate Format: X.509 or PKCS-6

3.4.3 개요
  1. 새로이 도입된 Anchor, Method
    새로운 프로토콜 지시어로 "shttp"를 사용한다. 즉 S-HTTP로 통신을하는 Anchor의 URL은 shttp://.../형태로 새로이 제안되었다.
    또한 요청(request)포멧은 "Secure url Secure-HTTP/1.1"형태로서 새로운 Method "Secure"를 새로이 정의해서 사용한다.
    New info in shttp anchors: DN, NONCE, CRYPTOPTS HTML extensions: CERTS and CRYPTOPTS
  2. 구현
    • NCSA :
    • Terisa :
    • OpenMarket :
    • Chicago University :

  3. 동작원리
    S-HTTP는 HTTP처럼 Request-Response구조를 가지고 있다. 다만 HTTP와는 다른 S-HTTP용 헤더정보를 통해 암호화방식에 대한 파라메터들을 주고받으면서, 서로 어떤 암호화방식으로 어느정도 암호화해서 주고받을것인가를 사전조율한다.
    예를들면
    "You may use DES when encrypting." "I insist on using DES when encrypting." 일반적인 경우에
    서버는 초기에 기본적으로 다음과 같이 지정한다.
    • "브라우져는 암호화(Encrypt)를 해야한다."
    • "서버는 전자서명(Sign) 혹은 암호화(Encrypt)는 할수도 있고 안할수도 있다."
      SHTTP-Privacy-Enhancements: orig-optional=sign, encrypt; recv-required=encrypt
    • "트랜젝션에 사용될 키는 ...방법을 써서 교환하자."
      SHTTP-Key-Exchange-Algorithms: recv-required=RSA; orig-optional=Inband, RSA
    • "서버의 Public 키는 ...이다."

  4. 예(Example)
    Content-Privacy-Domain: PEM, PKCS-7, PGP Content-Transfer-Encoding: 8-bit, Base64, 7-bit Prearranged-Key-Info: ..... etc. Encapsulated content (encrypted and/or signed)
3.4.4 전송되는 문서의 암호화상태
  1. Unprotected : 암호화하지 않은 문서
  2. Signed : 전자서명이 된 문서
  3. Encrypted : 암호화가 된 문서
  4. Signed and Encrypted : 암호화하고 전자서명을 한 문서

3.4.5 S-HTTP Implementation Status
  1. NCSA : 94년 2월에 시작해서 94년 10월에 구현을 완료했었다. 구현범위는 서버는 Unix시스팀에만 구현했고 브라우져는 모든 플랫폼에서 다 구현이 되었었다. 이는 CommerceNet컨소시움에서 의뢰해서 개발된 것으로 해당 컨소시움 멤버에게 제공되었다.
  2. Terisa Systems : 상업용으로 테리사(terisa)시스팀에서 구현해서 현재 개발툴킷으로 판매하고 있다. SecureWeb Toolkit(http://www.terisa.com/prod/index.html)이라는 이름의 제품을 판매하고 있다. 이 제품의 특징은 S-HTTP와 SSL을 모두 구현해두어서 한 툴킷으로 두 프로토콜응용 제품을 개발할수 있다는 장점이 있다.
  3. Open Market, Inc : Open Market사는 Secure WebServer(http://www.openmarket.com/products/servers/secure.htm)라는 이름으로 서버측의 S-HTTP구현 제품을 판매하고 있다.

3.5 SSL

SSL(Secured Socket Layer)은 테리사(Terrisa)가 개발해 Netscape사가 Netscape과 NetSite의 암 호화 중심프로토콜로 사용하는 프로토콜이다. SSL은 서버와 클라이언트간에 인증 (Certification)으로 RSA방식과 X.509 를 사용하고 실제 암호화된 정보는 새로운 암호화 소 켓채널을 통해 전송하는 방식이다. SSL은 특히 네트웍레이어의 암호화방식이기때문에 HTTP뿐아니라 NNTP, FTP등에도 사용할수 있는 장점이 있다. 그러나 또 한편으로는 일반적으로 네트웍레이어에서의 암호화 프로토콜은 이미 제안된 방식들 (IPSP, IPNG등이 IETF에서 논의중이고 Keberos가 암호화채널을 지원하는데 굳이 새로운 SSL이라는 네트웍레이어의 프로토콜을 추가 할 필요가 있겠느냐는 비판도 있다.

3.5.1 SSL사양
SSL은 현재 버젼 3.0으로 사양은 http://home.netscape.com/newsref/std/SSL.html에 나와있으며

등을 사용한다.

3.5.2 SSL프로토콜 Overview
  1. 프로토콜 버젼등 확인
  2. 사용할 암호화기법과 수준을 결정
  3. 서로를 확인(Authetication)함 - 이 작업은 옵션
  4. 암호화기법과 키들을 주고받으며 서로 negotiation
  5. Session키를 생성하고
  6. 새로운 채널(포트 443번)을 통해 암호화된 통신을 함.

프로토콜 Overview client Server ClientHello -----------> ServerHello Certificate(optional) ServerKeyExchange(optional) CertificateRequest(optional) <----------- ServerHelloDone Certificate(optional) ClientKeyExchange CertificateVerify(optional) ChangeCupherSpec [Begin new CipherSpec] Finished --------------> ChangeCipherSpec <------------ Finished Application DATA <--> Application DATA

3.5.3 SSL Implementations
  1. SSLRef (Version 2.0)
    SSLRef는 시스팀개발자들이 쉽게 SSL프로토콜을 이용할수 있도록 API를 만들어 둔 것을 말한다. SSLRef는 ANSI C코드로 만들어져있고 많은 플랫폼에 이식되어서 SSL프로토콜을 이용해 프로그램을 만들려는 사람들에게 소스코드까지 제공되고있다. 현재 넷스케이프에서 배포하는 SSLRef는 비상업용으로는 무료로 사용할수 있게 되어있으나 애석하게도 미국내에서만 얻을수 있다.
    SSLRef에 대한 정보가 있는 페이지는 http://home.netscape.com/newsref/std/sslref.html에 있으며 자세한 정보는 ssl@netscape.com로 메일을 통해 얻을수 있다.

  2. 미국 밖에서의 SSL - SSLeay SSL프로토콜을 이용해 미국밖에서 SSLRef와 똑같이 구현한 시스팀이 있다. 호주의

  3. SSLRef in the outside of USA
    호주의 Eric Young(eay@mincom.oz.au)이 SSL 2.0을 구현한 라이브러리를 공개했다. 이 라이브러리는 상업적이든 비상업적이든 무료로 사용할 수있게 되어있고, 위치는 ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/에 있다.
    재미있는 사실은 Eric Young이 만든 SSLeay를 이용해 Tim Hudson(tjh@mincom.oz.au)이 SSL을 응용한 응용 프로그램을 많이 만들었다. 예를들면 SSLtelnet, SSLftp, NCSA Mosaic 2.5, 2.6b1, 2.6b2, NCSA httpd 1.3, 1.42등이다.

3.6 SEA(Security Extension Architecheture)

3.6.1 SEA(Security Extension Architecheture) 개요
SEA는 W3C에서 최근에 만들고 있는 WWW Security프로토콜이다. 위에서 언급한 WWW보안 프로토콜들이 있음에도 불구하고 W3C에서는 SSL/S-HTTP두 프로토콜의 약점이 있다고 판단하고 HTTP프로토콜과 더 밀접하게 관계를 가지는 새로운 보안프로토콜을 제안했다. (새로운 보안프로토콜이라기보다도 HTTP의 Security확장이라고하는게 더 정확한 표현이다.) SSL은 Transport층의 보안프로토콜이고 S-HTTP는 HTTP와는 비슷한 구조이지만 별도의 새로운 프로토콜이어서 기존의 HTTP와의 호환성의 문제등을 W3C에서는 문제시하고 있다.
SEA는 S-HTTP의 기능을 수용하면서 구현은 W3C에서 최근 제안한 PEP을 이용하는 형태를 띄고 있다. SEA를 이해하려면 PEP(Protocol Extension Protocol)의 구조를 이해해야한다. PEP은 HTTP프로토콜을 사용자레벨에서 정의해서 확정할수 있는 "프로토콜 확장 플랫폼"프로토콜이다. SEA는 이 PEP를 이용해 첫번째 구현으로 SEA구현을 시도하고있다.
PEP에 대한 정보는 http://www.w3.org/pub/WWW/TR/WD-http-pep.html에 있고, SEA에 대한 정보는 http://www.w3.org/pub/WWW/TR/WD-http-sea에 있다.

3.6.2 SEA의 중심 클래스.
  1. 전자서명 : HTTP프로토콜로 주고받는 메시지(Body)에 대해 전자서명을 한 후, 이를 HTTP헤더에 추가해서 주고받는 메커니즘이다. 이렇게 하는 장점은 (1) 기존시스팀에 쉽게 추가할 수있고, (2) 다른 보안메커니즘으로부터 전자서명을 분리시킬수 있으며, (3) 과거버젼의 HTTP와도 호환성을 유지할수 있다. 즉 서명된 문서를 이전버젼의 브라우져가 볼때도 볼수는 있다.

  2. 암호화 : HTTP Body를 암호화한다. 여기서 사용될 암호화 방식은 아래에 설명될 키교환으로 얻어진 세션키를 이용해 암호화한다.

  3. 키교환 메커니즘 : 주고받는 내용을 암호화하기위한 키를 서로 생성해서 주고받는 메커니즘으로 여기서는 RSA혹은 Diffie-Hellman방식을 사용해서 세션키를 주고받는다.

3.6.3 SEA를 사용하는 예
  1. 전자서명
    서버측에서 서명된 문서를 브라우져에게 전달하는 과정 C->S: GET /Platform.html HTTP/1.1 Accept-Protocol: {http://w3.org/SEA/Signature {str req}} S->C: 200 OK Protocol: {http://w3.org/SEA/Signature/RSA-MD5 {params {pk Base64(A's PK)} {name "A@S"}} {headers Signature-37}} Signature-37: Base64(the signature of the reply, PKCS-1 packed)
  2. 암호화 통신
    시나리오 : C는 현재 어떤 Public키도 가지고 있지않는데, Y(암호화)서버의 문서를 보려고 한다. 이때 해결책은 Y가 자신의 Public키를 C에게 전달하고 C는 세션키를 생성해 Y의 Public키로 암호화해서 Y에게 전달하면 (키교환), Y는 C로부터 받은 세션키와 C가 지정한 암호화방식으로 문서를 암호화해서 보여준다.
    C->Y: GET / HTTP/1.1 Y->C: 200 OK Accept-Protocol: {http://w3.org/SEA/Key-Exchange/RSA {params {pk Base64(Y's PK)} {name "Y's PK"}}} C->Y: WRAPPED * HTTP/1.1 Protocol: {http://w3.org/SEA/Encryption/DES {str req} {params {IV Base64(iv)} {keylen 56} {pad n} {mode cfb} {keyname "C's New Key"}}} Protocol: {http://w3.org/SEA/Key-Exchange/RSA {str req} {params {pad n}} {headers DEK-Info-15}} DEK-Info-15: Base64(C's New Key encrypted by Y's PK) Content-Type: text/html Content-Encoding: rsa, des E GET /SensitiveData HTTP/1.1

3.7 기타

3.7.1 PGP Web from NCSA - Not Popular
3.7.2 Shen from CERN
3.7.3 GSSAPI integration (RFC1508)

4. WWW보안시스팀이 모든것을 다 해결하는가?

WWW보안시스팀이 많이 제안되었고, 또 활발히 개발되고 있다. 그러나 WWW보안시스팀이 일반적인 WWW보안에 적용할 수는 있겠으나 모든 응용시스팀을 다 해결한다고 볼수는 없다. 특히 전자지불, 전자현금 영역에 있어서는 중복되는 영역도 많지만 긍국적으로는 다른 영역의 응용시스팀이라고 할수 있다. 특히 전자지불/전자현금 시스팀은 WWW처럼 두개의 호스트(브라우져/서버)간의 관계가 아니라 고객-상점(-지불브로커)-은행등 3자/혹은 4자간의 관계로 만들어지는 메커니즘이며, 실제로 상거래를 이루는 프로토콜이므로 그 자체로 필요한 보안요소가 있다.

4.1 Payment Spesific Security

  1. Merchant로부터 PIN정보(고객의 금융/개인정보)의 보호
  2. 사용자의 Privacy - Blind Signature
  3. Double Spending
  4. 지불부인의 방지- Signature

4.2 사용자들의 편의성

또한 보안의 요소뿐 아니라 전자상거래를 하는 사용자들의 편의성의 측면에서도 WWW보안시스팀만으로는 여러가지 단점을 가지고 있다.
  1. 서버마다 다른 사용자 인터패이스
  2. 구매시마다 동일한 지불행위

5. 전자화폐

5.1 전자지불시스팀의 원리

전자지불시스템은 겉으로 보기에는 동일한 것처럼 보이지만 내부적인 매커니즘을 살펴보 면 크게 두가지로 대별해 볼 수 있다. 하나는 지불브로커시스템(Payment Broker)이고 또하 나는 전자현금(Electronic Money)시스템으로 구분 할 수 있겠다.

  1. 지불브로커(Payment Broker)시스팀 : 독립적인 신용구조를 가지고 있지 않고 신용카드나 은 행의 계좌를 이용해 네트웍상에서 지불을 하도록 연결시켜주는 구조로 되어있다. 이런 시 스템은 신용카드를 이용한 거래의 관행이 자리잡혀 있고 이의 응용이 용이하기때문에 현재 많이 이용되고 있는 현실적인 전자지불시스템이다. 그러나 신용카드의 수수료등이 매우 비싸며 비효율적이며 사용자들의 개인정보(거래정보)의 비밀보장이 되지않는다는 단점이 있다. 이 방식은 현재 임시적인 방식이며 향후 사용이 줄어들것으로 전망한다.

    • First Virtual
    • CyberCash

  2. 전자화폐(Electronic Cash)시스팀 : 아직은 실용화되기에는 이른 감은 있지만 이론적으로 그리고 실험적으로 많이 연구되고있으며, 전자지불시스템이 지향하는 궁극적인 목표시스템 이다. 이는 선불카드/직불카드를 응용하거나 순수한 디지털현금을 응용하는 시스템이다. 이 들을 만들만한 기술적인 준비는 상당히 진전되었지만, 현재 금융과 사회적관습 그리고 통 화량과 경제에 미치는 영향등 사회경제적인 관점에서는 아직 깊은 연구가 이루어지지는 않 는듯하다.

    선불/직불카드응용의 예

    • NetCheques
    • NetBill
    • smartcards

    전자화폐 시스팀의 예

    • ecash (Digicash)
    • NetCash

5.2 현황

5.2.1 개발및 제안된 프로토콜 현황

5.2.2 전자지불/전자화폐서비스 관련 기업들의 현황
  1. 초기의 선구자
    • 디지캐시(DigiCash)사 : 디지캐시(DigiCash)사의 D. Chaum은 여러가지 실험적 전자지불프로토콜을 제안하고 구현했으며 블라인드전자서명을 고안해낸 장본인이기도 하다.
    • FV사 : FV사 역시 MIME을 고안해내고 MetaMail을 만든 Nathaniel Borenstein등과 같은 인터넷상의 쟁쟁한 기술자들이 모여서 만든 기술중심의 회사이다.

  2. 후발 주자
    전자지불서비스가 인터넷상에서 현실적인 요소로 등장하자 관련회사들은 앞을 다투어 전자지불프로토콜을 개발하고 서비스를 제공하겠다고 나섰다. 대표적인 후발주자는 비자(VISA), 마스타(Master), 유로피(Europay)등 굵직한 신용카드회사들이 중심이 되고 있다. 여기에 마이크로소프트, IBM, 넷스케이프등 정보통신시장에 진출하려는 컴퓨터회사들이 서로 연합해서 편을 갈라 서로 경쟁하고 있다. 서로 경쟁하면서도 특정 분야에서는 서로 연합하는등 복잡한 현상을 보이고 있는 곳이 바로 전자지불시스템시장이다.
    • 비자카드사는 마이크로소프트와 함께 STT(Secure Transaction Technology)(13)라는 신용카드응용 전자지불프로토콜을 지원하기로 했다. 이는 94년 11월부터 공동작업을 시작했던 사항이다. 아직 STT를 지원하는 지불소프트웨어를 볼수는 없지만 계획에 의하면 마이크로소프트는 이 STT지불시스템을 자사의 컴퓨터통신서비스인 MSN(Microsoft Network)을 통해 전자지불을 95년말부터 시작할 계획이었고, 96년부터는 인터넷의 WWW서비스에 적용할 계획이었다. 원래 마이크로소프트는 STT개발을 마스타카드와 제휴를 원했는데, 마스타카드사는 마이크로소프트사가 크레디트카드분야에 영향력을 갖는것을 경계해서 거절했다고 전해진다. 한편으로는 비자는 넷스케이프와도 여러가지 전자지불과 정보통신관련 협약을 맺으며 접근하고 있는 것이다.
    • 마스타카드사는 인터넷을 통해 급성장하고있는 넷스케이프사의 Secure Courier(11)라는 전자지불프로토콜을 지원하기로하고 제휴관계를 시작했다.
    • 유로피(Europay International)는 IBM과 제휴를 하고 iKP(10)프로토콜을 이용한 전자지불서비스를 시작하기로 했다.
    • 유로피는 마스타카드가 출자한 회사로서 마스타카드의 영향력속에 들어있기때문에 전자지불프로토콜시장은 비자와 마스타의 경쟁, 그리고 마이크로소프트와 IBM, 넷스케이프연합과의 경쟁이라는 큰 두 축으로 갈라서게 되었다. 이는 마이크로소프트와 IBM이 컴퓨터분야에서 숙명적인 라이벌이며, 인터넷에서는 마이크로소프트와 넷스케이프간에는 치열한 경쟁이 일어나는 것과 무관하지 않는 것 같다.
    • 그러나 STT, Secure Courier 그리고 iKP등의 내부는 사실상 거의 같은 모양과 기술을 조금씩 다르게 포장한 것에 불과하다.
    • 또한 최근 비자와 마스타는 새로이 공통프로토콜 (SET)을 정의하고 함께 활동하기로 하기도 했다.
    • 유럽은 유러피와 IBM의 활동과는 별개로 디지캐시사가 오래전부터 활동했으며, 4년전인 1992년부터 CAFE라는 네덜란드, 덴마크, 영국, 프랑스, 독일등 유럽 13개국이 연합해서 전자지불프로토콜을 표준화하고 개발하는 프로젝트가 진행중이다.
    • EBC(Electronic Business Cooperative)연합 : 카드신용조회회사인 체크프리(CheckFree)사 와 컴퓨터회사 그리고 스파이글래스(Spyglass)사등이 연합한 EBC(Electronic Business Cooperative)연합은 독자적인 EBC Wallet(22)을 만들어 스파이글래스 모자익 2.11버젼에 탑재해서 96년 1월에 출시하기로 되어있다. 특히 EBC Wallet의 암호화방식은 Bulk암호화가 아니어서 미국 밖에서도 40bit이상의 키이를 사용할수 있는 장점이 있다.

  3. 스마트카드기반의 전자지불시스템
    지금까지는 네트웍과 컴퓨터소프트웨어를 응용한 전자지불프로토콜을 주로 이야기 했었다. 그러나 향후의 전자지불시스템은 컴퓨터소프트웨어를 기반으로한 가상지갑(Virture Wallet)과 스마트카드(IC카드)를 기반으로 한 IC카드시스템 두가지로 발달될 것이라는 추측이 지배적이다.
    • 비자와 마스타카드 그리고 유로피가 신용카드를 IC카드화하기위한 통일사양인 EMV(Europay, Master and Visa)사양을 95년 6월에 만들었다. 그리고 비자와 마스타는 향후 5년이내에 지금의 플래스틱 신용카드를 전부 IC카드로 전환하기로 계획하고 있다. IC카드의 사용은 전세계적으로 보급된 기존의 카드조회단말기를 IC카드를 인식하는 단말기와 필요한 소프트웨어로 교체해야하는 어려움이 있긴하지만 지속적으로 확산될 것이다. EMV사양의 IC카드는 기존의 신용카드와 동일한 기능을 하지만, 내부의 기술적으로는 소프트웨어 가상지갑에서 사용가는 공개키암호화(Public Key Encription)기법을 이용한 암호화를 사용하고있다. 또한 IC카드는 전자현금적 기능을 가질수가 있어서 현금지급기(ATM)에서 일정금액(Value)을 미리 인출해서 IC카드에 담고다니면서(Stored Value) 상품을 살때 이 금액(Value)을 지불할 수가 있다. 이는 선불/직불시스템을 응용한 전자현금과 같은 방식이다.
    • 이런 IC카드의 실용화를 위해 마스타카드사는 95년부터 호주의 킴베라시에서 4개은행, 1000개의 상점, 1만명의 사용자를 대상으로 실험서비스를 시작했다고 하며,
    • 비자는 96년중으로 미국이나 아시아지역에서 대규모의 실험을 하기로 계획하고 있다고 한다. IC카드의 장점은 네트웍세계가 아니라 실세계에서 이동하면서 사용할수 있다는 점이다. 향후에는 컴퓨터에 플로피디스크드라이버가 기본으로 장착되는 것처럼 IC카드리더기가 보급될 것으로 보인다.
    • 유로피는 96년에 IBM의 iKP소프트웨어와 컴퓨터, IC카드리더기를 장착한 IC카드와 소프트웨어 전자지불서비스를 통합하는 실험을 하기로 되어있다.
    • 몬덱스 : IC카드를 이용한 전자지불서비스에 있어서 가장 앞선 프로젝트는 바로 영국의 몬덱스(Mondex)(23)이다. 몬덱스는 영국의 NatWest은행과 Midland은행이 중심이되어 95년 7월부터 IC카드를 이용한 전자현금서비스를 시작했다. EMV와 몬덱스의 차이점은 EMV는 신용카드를 이용하고 몬덱스는 은행을 이용한다는 점이다.

  4. 관련회사들의 움직임
    • VeriFone : 미국의 카드 신용조회 회사 가운데 최대회사인 VeriFone사는 CommerceNet컨소시움(24)의 간사회사이며 S-HTTP프로토콜을 만들어서 유명한 EIT(Electronic Integration Technologies)사를 95년 8월에 매수했다. VeriFone은 또 미국의 전자지불전문회사인 사이버캐쉬(CyberCash)사에 자본을 투자하기도 했다.
    • EIT : EIT사는 이보다 조금 일찍 RSA사와 합작으로 Terisa라는 시큐리티소프트웨어전문회사를 설립해 SSL이라는 암호화프로토콜과 소프트웨어를 만들어 넷스케이프의 표준시큐리티모듈로 사용하고 있다.
    • VeriSign & RSA : RSA는 또 VeriSign이라는 인증전문회사를 설립했고 넷스케이프의 브라우져와 서버는 이 VeriSign사의 인증을 받도록 되어있다.
    • Intuit : 마이크로소프트사는 미국의 홈뱅킹소프트웨어 퀴큰(Quicken)으로 유명한 인튜이트(Intuit)사를 매수하려다가 독점 방지법에 고소를 당해서 포기했다. 인튜이트사는 미국시장의 점유 1위를 차지하는 퀴큰소프트웨어에 전자지불기능을 추가해서 서비스를 시작했다.
    • Netscape : 넷스케이프는 전자지불과는 약간 다르지만 자사의 강력한 무기인 넷스케이프네비게이터 소프트웨어를 VeriSign에 인증등록을 하면 인터넷상에서 거래에서뿐 아니라 메일이나 뉴스등을 사용할때도 그 내용과 진실성을 인증받을수 있도록 하는 포괄적 인증방식을 구현해서 제공한다. 이를 이용하면 사용자는 네트웍 상에서의 모든 활동에 법적인 지위를 확보 할수 있기때문에 사이버스패이스에서의 상업적이고 공식적인 잠재성을 넓혀놓았다고 볼수 있다.

5.2.3 전자지불 표준화 활동
전자집불프로토콜을 기업들이 주도를 하고있긴하지만 다양한 프로토콜이 제안되면서 사용자들의 혼란을 야기할 가능성이 생기자 여러 프로토콜을 표준화하려는 움직임이 있다.

  • W3C의 Payment W/G과 CommerceNet컨소시움의 Joint Working
  • IETF working group : ietf-pay W/G 이 95년 12월에 생성되었다.

5.3 SoftCash - 한국적 전자화폐 시스팀

전자화폐는 앞으로 그 사용에 있어서 조만간에 신용카드의 수준을 넘어설것이 분명하다. 더우기 이는 네트웍상에서 흘러다니기때문에 금융정책등으로 장벽을 만들기는 상당히 힘들다. 앞으로는 국가의 외환정책과는 상관없이 개인이 아무런 문제없이 외국의 전자은행에 계좌를 개설하고, 전자 현금으로 외국의 기업을 상대로 거래를하고 지불을 할수 있을 날이 올 것이다. 미국의 SFNB는 현 재는 비록 자국의 시민권자에게만 계좌를 개설하지만 네트웍으로 환금화가 좀더 원활해지만 분명히 외국인에게도 계좌개설을 허용할 것이다. 네트웍상의 전자상거래를 하는 기업들은 네트웍상의 전자 은행에 계좌를 두는 것이 거래를 원활하게하는데 도움이 될 것이므로 전자은행/전자화폐의 사용은 점점 증가할 것이다.

6. 결론

보안시스팀은 사이버스패이스에서의 활동에 법적인 효력을 부여하는데 중심적 역할을 한다. 지금까지는 네트웍상에서 일어나는 일은 다만 취미 혹은 관심의 영역에서 벗어나지 않았다. 그러나 이제 보안의 문제 가 해결되면 사이버스패이스에 본격적인 사이버 소사이어티, 전자상거래등이 일어날 것이다. 이런 흐름은 산업혁명이후 가장 거대한 변화의 흐름이라 할 것이다. 전자상거래/전자지불/전자화폐는 자본주의의 20세기 그리고 21세기의 중심적 요소가운데 하나가 될 것이며 이에 대한 적절한 대응이 바로 21세기를 준비하는 첫걸음이 될 것임을 확신한다.

참고문헌

[IEEE Press 95]
Network And Internetwork Security
William Stallings
[O'Reilly & Associates 95]
World Wide Web Journal
Fourth International World Wide Web Conference Proceedings
[ O'Reilly & Associates 95]
PGP (Pretty Good Privacy
Simson Garfinkel
[WWW-KR95a]
가자, Web의 세계로! ,341p-347p