전자서명법과 공인인증서(in progress)
- 인증서
- 잠금(암호화)기술 등이 컴퓨터에서 구현되는 구조
- 국내의 암호화 응용프로그램 개발 현황
- 정통부의 처분이 전자서명법에 위반되는 이유
- 즉시 실행 가능한 대안들
- 위법한 현 상황을 시정하는 방법
- 현재의 솔루션에 새로운 솔루션을 추가하는 방법
- 현재의 솔루션을 새로운 솔루션으로 대체하는 방법
- 정보통신부 장관의 책임와 의무
- 장기적 계획
1. 인증서
인증서가 수행하는 기능은 크게 보아 두가지 입니다. 정보를 암호화 하는데 필요한 " 잠금쇠" 역할과, 교신 상대방이 누구인지를 기술적으로 확인하는 "신원확인" 기능입 니다.
공인이건 사설이건 간에, 인증서의 잠금기능은 SSL (secure socket layer) 또는, 그 후속 기술이라 할 TLS (Transport Layer Security) 기술 기반을 전제로 합니다. SSL/ TLS 기술 기반은 공개키(public key)와 비밀키(private key)를 한 쌍으로 사용하여, 교신 당사자 간에 오가는 정보를 제3자가 알 수 없도록 암호화하는 기능을 수행합니다. 갑과 을 간에 교신을 할 때, 갑은 을이 제공한 공개키를 사용하여 자기가 보낼 정보를 "잠근(encrypt)" 다음, 네트웍을 통하여 을에게 전달합니다. 이렇게 전달되는 정보뭉치는 오로지 갑이 사용한 잠금쇠(을이 준 공개키)와 한쌍을 이루는 열쇠(을이 가지고 있는 비밀키)가 있어야 열어볼 수 있습니다.
이 기술을 인터넷에 응용한 것이 인증서 제도 입니다. 모든 컴퓨터들이 서로 잠금쇠를 주고 받는 대신, 인증기관(Certificate Authority, CA)을 매개로 하여 잠금쇠가 제공되도록 하고, 그 잠금쇠를 받은 개별 컴퓨터는 그것이 믿을 만한 것인지를 확인, 판단하고 그것으로 정보를 잠근 다음 네트웍을 통하여 상대방에게 보내는 것입니다. 이러한 방법을 공개키 기반구조(Public key infrastructure; PKI)라고 합니다.
인증서 파일은 잠금쇠 뿐 아니라, 잠금쇠를 누가 제공하고, 그 사실을 누가 인증했는지에 대한 정보도 담고 있으므로, 내가 교신하는 상대방이 과연 내가 생각하는 그 당사자 인지를 확인하는 기능도 수행합니다. 예를 들어, 인터넷 사용자(A)로서는 자신이 접속한 웹사이트(B)에서 보내온 잠금쇠(공개키)가 과연 B가 보낸 것인지를 확인할 필요가 있고, 웹사이트(B) 입장에서도, 누가 A 라면서 접속요청(예를 들어 전자민원신청)을 해오는데 과연 그자가 A가 맞는지를 "기술적"으로 확인할 필요가 있을 수 있습니다. 인증서는 이것에 필요한 정보(서명정보)를 담고 있습니다.
2. 잠금(암호화)기술 등이 컴퓨터에서 구현되는 구조
정보는 암호화 알고리즘(encryption algorithm)을 적용하여 잠그어 집니다. 암호화 알고리즘은 여러가지가 있는 바(인터넷 백과사전인 Wikipedia 에 소개된 것만도 약 60 여 가지가 됩니다), 3-DES, BlowFish, IDEA 등과 함께 한국이 독자 개발한 SEED가 있습니다.
이러한 알고리즘은 암호화의 "원리"만을 제시할 뿐, 그것을 응용하여 컴퓨터 프로그램(application)으로 만들기 위하여는 다음과 같은 단계가 필요합니다.
첫째, 그 암호화 원리를 응용한 프로그램을 만들기 위하여는 그 원천이 되는 소스파일을 작성하여야 하는데, 이때 각 단계에서 필요한 기능을 수행하도록 "불러와 쓸 수 있는" 이진(binary) 파일로 된 라이브러리가 필요합니다. 예를 들어, 3-DES 알고리듬을 구현할 수 있는 라이브러리로는 미국의 RSA Security 라는 회사가 개발한 BSAFE Crypto-C, Crypto-J 등의 라이브러리가 있고, 그 회사는 이 라이브러리에 대하여 특허권을 가지고 있습니다. 한편 DSA (digital signature algorithm) 라는 알고리즘을 구현할 수 있는 라이브러리 중에는 OpenSSL 이라는 이름으로 개발된 라이브러리가 있고, 이것은 공개소스로서 상용(商用) 여부를 불문하고 대부분 무료로 사용할 수 있습니다. 이 공개소스를 기초로 하여, 국산 SEED 알고리즘을 구현한 라이브러리는 장 혜식님이 2001. 경에 시안을 만들어 둔 것이 있습니다.
둘째, 어떤 응용프로그램이든 그것이 컴퓨터에서 가동되는 과정에서는, 컴퓨터의 여러 기능과 서비스에 의존하게 됩니다. 컴퓨터의 운영체제(OS)를 기반(platform software)으로 삼아, 응용프로그램은 그 위에서 가동되는 구조 입니다. 이처럼 운영체제와 응용프로그램 사이의 연락을 가능하게 해주는 것을 API (application programming interfaces)라고 합니다. 이상적으로는 이 API는 특정 응용프로그램이나, 특정 알고리즘에 의존하지 않도록 설계함으로써 다양한 알고리즘과 그를 구현하는 프로그램이 동일한 OS에서 가동될 수 있도록 하고, 그 규격(specifications)이 정확히 공개되면 다양한 OS가 해당 프로그램이 필요로 하는 기능과 서비스를 제공할 수 있게 되므로 같은 프로그램이 윈도즈, 매키토시, 리눅스, 유닉스 등의 운영체제에서 가동될 수도 있게 됩니다. 유닉스 환경에서는 이러한 관행과 예절이 잘 지켜지는 편 이지만, 마이크로소프트(MS)사는 API 규격 공개를 꺼리거나, 매우 부실한 공개를 하는 실정입니다. (MS 사의 독점적 지위 남용에 대한 유럽연합 공정거래당국의 결정문 para. 41, para. 1013(i) 참조.) 현재 암호화 프로그램용 API로는 GSS-API, Cryptoki 등이 국제표준으로 인정받고 있고, MS사 고유의 Crypto API 는 국제표준으로 인정받지는 못하나, "한국내 표준"으로 되다시피한 상황입니다.
[개념도]
셋째, 암호화 및 인증확인 기능을 수행하는 응용프로그램은 단독(stand-alone)프로그램의 형태로 배포, 판매 될 수도 있고, 웹브라우저나 이메일 프로그램에 장착 (built-in)되어 배포되기도 합니다. IE, Firefox, Opera, Safari, Thunderbird, Evolution 등은 이미 그 자체에 RSA 알고리즘, DSA, 3-DES 등의 알고리즘을 SSL (또는 TLS) 프로토콜을 통하여 구현할 수 있는 응용 모듈이 장착되어 있습니다. 그동안 IE 브라우저는 경쟁 제품인 Firefox 등에 비하여 암호화 구현에 상당히 뒤져, 보안에 취약하다는 평가가 있었고, 이 사태가 장차 배포될 IE7 에서 시정될지는 아직 불분명 합니다. 우리의 공인인증서에 사용되는 프로그램들은 단독프로그램과 장착 모듈의 중간 형태라고 할 수 있는 브라우저 플러그인(browser plugin)의 예입니다. 플러그인의 의미에 대하여는 여기 참조. 그러나 신한은행이 그 고객에 한하여 제공하는 매킨토시용 인증서 처리 프로그램(EzPlus)은 단독 프로그램의 예입니다.
3. 국내의 암호화 응용 프로그램 개발 현황
퓨처, 이니텍, 장 미디어, STI, 트러스컴 등의 회사가 3-DES, SEED, RSA, DSA 등의 알고리즘을 처리할 수 있는 응용 프로그램을 개발하여 판매 중입니다.
| 개발사 | 암호 라이브러리 | API | 지원 알고리즘 |
|---|---|---|---|
| 퓨처 | CrypTool (C) | Cryptoki(PKCS#11)? | 3-DES, SEED, RSA, DSA |
| 이니텍 | INICrypto (C) | - | 대체로 같음 |
| STI | J/LOCK (Java) | JDK 1.2 | 위와 같음 |
| 장미디어 | SEAL98 (Java) | - | 같음 |
[출처: 주학수, 이언경, 김승주, "암호라이브러리 및 암호 API 개발 현황", 정보보호 학회지, 제12권 제4호 (2002.8.)]
그러나 국내 어느 회사도 암호 라이브러리나 제대로 정리된 API를 공개한 곳이 없습니다. 따라서 이들이 SEED 알고리즘을 국내 시장에서 구현하고는 있으나, SEED가 국제적으로 알려지고 확산되는데 그다지 큰 기여를 할 가능성은 없는 사정입니다. SEED를 지원하는 라이브러리를 공개소스로 개발하여 국제적 인지도를 높이려는 국내 인력의 노력은 위에 언급한 장혜식님의 openSEED 프로젝트가 유일한 것입니다. 반면에 RSA Security 사의 BSAFE 상용 라이브러리와 리눅스 기반에서 공개소스로 개발된 Botan (C++) 라이브러리는 SEED 알고리즘을 지원하고 있습니다. SEED 알고리즘 그 자체의 우수성은 전문가들 사이에 비교적 좋은 평가를 받고 있는 것으로 보입니다. 그러나 국제적 인지도는 아직 그리 높지 않습니다. Wikipedia에 SEED를 소개한 글의 첫 문장은 다음과 같이 시작됩니다:
SEED is a block cipher developed by the Korean Information Security Agency. It is used broadly throughout South Korean industry, but seldom found elsewhere.
[SEED는 한국 정보보호진흥원이 개발한 블록 암호화 알고리즘이다. 이것은 한국 내에서 널리 사용되고 있으나, 다른 곳에서는 거의 볼 수 없다.]
더욱이, 퓨처, 이니텍 등의 회사가 개발한 응용프로그램은 모두 MS사의 ActiveX 기술을 사용하고, 이 기술은 다른 운영체제와 호환성이 없으므로, 한국과 같이 극심한 MS 독점을 당연시 하는 외국이 있다면 모르겠으되, 그렇지 않은 이상, 우리의 SEED가 이들 응용프로그램을 통하여 외국에 알려질 가능성은 원천적으로 막혀 있다고 하겠습니다.
4. 정통부의 처분이 전자서명법에 위반되는 이유
공인인증 업무를 취급하려는 자는 정보통신부 장관의 인가를 받아야 합니다(전자서명법 제4조). 정보통신부 장관은 신청자가 관련법규에 규정된 요건을 충족 하는지를 심사하여 공인인증기관으로 지정할지 여부를 결정하도록 되어있고, 이 심사절차의 자세한 사항은 전자서명법 시행령 제2조 및 제3조가 규정하고 있습니다. 현재, 한국정보인증(주), 금융결제원, (주)코스콤, 한국전산원, 한국전자인증(주), 한국무역정보통신이 공인인증기관으로 지정되어 있습니다.
그러나 이 어느 곳도 전자서명법이 규정하는 요건을 충족하지 못하고 있음에도 정보통신부 장관은 이들을 공인인증기관으로 지정한 위법이 있습니다. 그 이유는 다음과 같습니다.
전자서명법 제8조는 공인인증서 제도 운영의 기술적 측면을 규율하는 "전자서명인증 업무지침"(이하, "업무지침")을 마련하고 시행하는 근거가 되는 규정입니다.
현행 업무지침(2003.11.27. 발효) 중 이 사안과 직접 관련 있는 조항은 다음과 같습니다. 업무지침 제10조 제1항은 공인인증기관이 전자서명키를 생성할 때 적용하여야 할 알고리즘을 지정하고, 제11조 제1항은 서명생성키를 보호하는데 사용되어야 할 보안모듈을 지정하고, 제11조 제2항은 서명키 암호화에 사용 되어야 할 알고리즘, 그리고 제18조 제2항은 전자문서를 암호화할 때 적용되어야 할 알고리즘을 규정하고 있습니다.
업무지침에서 언급된 이들 각 알고리즘과 모듈에 대하여는 "공인인증기관의 시설 및 장비 등에 관한 규정"에 첨부된 "기술규격"에 그 기준이 제시되어 있습니다.이 기술규격은 한국정보보호진흥원이 마련하여 게시하고 있습니다.
이 기술규격은 특정한 하나의 알고리즘 이나 보안모듈의 사용을 강제하지 않습니다. 예를 들어, 암호 알고리즘(기술규격 2.3)은 3-DES 또는 SEED를 사용하도록 되어 있고, 3-DES는 오픈소스로도 널리 구현되어 있는 알고리즘입니다. 기술규격이 어떤 배타적인 구현기술이나 특정 OS 또는 특정 브라우저에 종속된 기준을 정해둔 것은 더더욱 아닙니다. 오히려 "공인인증기관 간 상호연동을 위한 사용자 인터페이스 기술규격"(기술규격 6.1)은 MS 윈도즈 운영체제와 그 외의 운영체제를 모두 염두에 두고 작성되어 있습니다. 특히 그 개정연혁을 보면, "비 MS 윈도즈 사용자의 편의성을 고려하여 기술규격[이] 개정"(2003.12.) 되었음을 분명히 알 수 있습니다.
공인인증기관으로 지정된 여섯 곳 모두, MS사가 판매하는 운영체제와 MS사의 브라우저를 동시에 사용하지 않으면 공인인증서의 발급신청 조차 할 수 없도록 하는 기술을 사용하고 있습니다. 이것은 전자서명법 하위 규정에 부속된 기술규격 미달이라는 문제에 그치는 것이 아니라, 근거법률 자체를 어기는 것입니다. 이하에서 자세히 설명하겠습니다.
전자서명법(이하, "법") 제7조 제1항은 다음과 같이 규정하고 있습니다:
공인인증기관은 정당한 사유없이 인증역무의 제공을 거부하여서는 아니된다.
법 제19조 제1항은 또한 다음과 같이 규정하고 있습니다:
공인인증기관은 자신이 발급한 공인인증서가 유효한지의 여부를 누구든지 항상 확인할 수 있도록 하는 설비 등 인증업무에 관한 시설 및 장비를 안전하게 운영하여야 한다.
법 제22조의2 제2항은 또한 다음과 같이 규정하고 있습니다:
공인인증기관은 이용자가 공인인증서에 의하여 다음 각호의 사항을 확인할 수 있도록 쉬운 수단을 제공하여야 한다.
- 공인인증기관의 명칭 등 공인인증기관임을 확인할 수 있는 정보
- 가입자가 당해 공인인증서가 발행된 당시에 전자서명생성정보를 지배·관리하고 있는 사실
- 공인인증서의 발행 전에 전자서명생성정보가 유효한 사실
인증서 발급신청자가 MS 제품을 사용하지 않는 것이 인증역무의 제공을 거부할 "정당한 사유"인지에 대하여 우선 살펴보겠습니다.
첫째, MS 제품을 사용하지 않는 자는 소수에 불과하다는 주장
이 주장은, 잘못된 정책으로 생긴 결과를 이용하여 잘못된 정책을 정당화 하려는 시도에 불과합니다. MS 제품의 시장점유율이 한국에서 유난히 높아진 이유는 한국의 인터넷환경이 MS 전용화 되어 있기 때문입니다. MS 제품을 사용하지 않으면 공인인증서를 발급 받을 수 없고, 공인인증서를 사용하지 못 하게 되는 순간, 이용자는 인터넷 상에서 "신원불상자", 정체불명의 위험 인물로 전락하게 되므로 조금이라도 (재산적 또는 비재산적으로) 의미 있는 인터넷 사용은 더이상 할 수 없게 됩니다. 이런 정책하에서 비 MS 제품 사용자가 늘어나기를 기대할 수는 없습니다.
세계 시장에서의 MS 운영체제(클라이언트 PC 용)의 시장 점유율은 다음과 같습니다:
| 운영 체계 | 2000 | 2001 | 2002 |
|---|---|---|---|
| MS Windows | 92.1 | 93.2 | 93.8 |
| 맥 OS | 3.9 | 3.1 | 2.9 |
| 리눅스 | 1.7 | 2.3 | 2.8 |
| 기타 | 2.4 | 1.3 | 0.5 |
[출처: MS 사에 대한 EU Competition Commissioner 의 결정문 para. 434]
*출하량 기준
그러나 같은 기간 동안 한국 내에서의 시장 점유율은 다음과 같습니다:
| 운영 체계 | 2000 | 2001 | 2002 |
|---|---|---|---|
| MS Windows | 3,715,135(98.5%) | 3,320,098(99.3%) | 3,504,029(99.4%) |
| 맥 OS | 26,100 | 6,790 | 14,489 |
| 리눅스 | 30,931 | 15,038 | 7,404 |
[출처: 한국소프트웨어진흥원/(주)한국IDC 자료(2004. 9.)]
공정거래위 심결 <표 3.5> *출하량 기준
정부는 독점의 폐해를 규제하고, 경쟁을 촉진함으로써 소비자의 권익을 보호할 의무가 있습니다(독점규제 및 공정거래에 관한 법률 제1조 참조). MS제품을 사용 안하는 자가 별로 많지 않으니 그들에게 인증서비스 제공을 거절함으로써 그 수를 더욱 줄이겠다는 것은 정부로서는 도저히 입에 담아서는 아니 될 말입니다.
그러나, MS윈도즈 운영체제를 사용하더라도 MS사의 웹브라우저(IE)를 사용하지 않으면 인증서비스를 제공받을 수 없습니다. 파이어폭스(Firefox)와 오페라(Opera) 웹브라우저는 적지 않은 윈도즈 사용자들이 선호하는 브라우저 입니다. 세계 브라우저 시장의 점유율은 다음과 같습니다:
| 브라우저 | 2005. 4. | 2006. 1. | 2006. 5. |
|---|---|---|---|
| MS IE | 86.63 | 85.82 | 85.17 |
| 파이어폭스 | 8.69 | 11.23 | 11.79 |
| 사파리 | 1.26 | 1.88 | 2.02 |
| 오페라 | 1.03 | 0.77 | 0.79 |
출처:
http://www.onestat.com/html/aboutus_pressbox42_microsoft_internet_explorer_has_slightly_increased.html
http://www.onestat.com/html/aboutus_pressbox37.html
국내 통계는 잘 알 수 없으나, IE 외의 브라우저도 MS전용화된 웹페이지를 그나마 조금이라도 더 처리하여 이용자에게 보여주기 위하여, 서버에게 자신을 마치 IE브라우저인 것처럼 "기술적"으로 보고하는 경우도 많으므로, IE 브라우저의 실제 시장점유율은 위의 수치보다는 낮습니다. 파이어폭스, 사파리 또는 오페라 웹브라우저를 선택한 이용자들에게 인증역무 제공을 거부함으로써 그들이 IE 브라우저를 쓰도록 압박을 가하는 행위는 그 숫자의 많고 적음을 떠나서 정부가 특정 브라우저의 배포와 확산을 편파적, 노골적으로 지원하고 있다는 의혹을 사기에 충분합니다. 잠재적으로는 국제 분쟁으로 비화할 염려도 없지 않습니다(이점은 후술).
둘째, 공인인증서 제도를 브라우저나 OS에 의존하지 않게 하려면 비용이 많이 들고 관리에 어려움이 있다는 주장
이러한 주장을 정부가 감히 제기한다는 것은 매우 놀라운 일입니다. 인증기관은 인증사업을 통하여 영리를 추구하는 주체입니다. 인증기관으로서는 저렴한 비용으로 많은 고객을 유치하고 이윤을 최대화하는 것이 당연한 관심사 입니다. 그러나 이들의 적나라한 이윤추구 욕망을 제어, 감독함으로써 우리의 전산환경이 왜곡되지 않게 하는 것이 정보통신부의 의무 입니다. 공인인증기관이 되려면 정통부 장관의 인가를 받도록 해 두는 이유는 바로 여기에 있습니다. "공인인증기관은 정당한 사유없이 인증역무의 제공을 거부하여서는 아니된다"는 조항을 전자서명법에 못박아 둔 이유도, 이 조항이 없으면 사업편의와 이윤극대화라는 私益추구에 골몰한 인증기관이 국가의 전산환경 전체를 엉망으로 만들고, 우리의 소프트웨어 산업에 치명타를 가하는 부당한 결과를 낳을 위험이 크기 때문입니다.
MS전용의 인증서 처리 솔루션을 채택함으로써 위 여섯 곳의 인증기관이 절약한 비용이 얼마가 될지는 잘 모르겠습니다. 그러나, 이들 기관의 사업규모는 다음과 같습니다(2005.1.1 - 2005.12.31).
| 인증기관 | 자산 규모 | 영업 수익 | 인증업무에 소요된 비용 | 영업 이익 |
|---|---|---|---|---|
| 한국정보인증(주) | 20,638,436,589 | 14,057,931,307 | ? | 1,296,203,294 |
| 금융결제원 | 2004년말 현재 | 전체 공인인증서의 | 71%를 발급하는 | 시장지배적 사업자 |
| (주)코스콤 | 157,735,905,431 | 176,713,893,508 | ? | 17,012,297,892 |
| 한국전산원 | 2005년 예산 => | 5,242억원 중 | 3,966억은 집행하고 | 1,276억은 이월 |
| 한국전자인증(주) | 2005년 자료 미입수 | ? | ? | ? |
| 한국무역정보통신 | 95,846,320,040 | 51,347,995,672(매출액) | ? | 13,935,662,378 |
마치 정통부가 이들 업체의 이익을 대변하는 하수인 인양, "비용이 덜 들고, 관리가 쉽다"는 이유를 내세워, MS전용화 된 배타적 솔루션으로 인증기관 지정신청을 해 온 이들 업체에게, 전자서명법 규정을 어겨가면서까지 인증기관 지정처분을 해준 결과, 우리의 소프트웨어 산업은 초토화되고, 우리의 전산환경은 MS에 예속되게 되었습니다. 2003.9.에 이미 정통부 소프트웨어진흥과 김영문 사무관(그 당시)은 "우리나라 소프트웨어산업은 미국에서 수입한 소프트웨어에 약간의 부가가치를 덧붙이는 수준" 이라며 "이런 구조를 바꾸지 않고서는 소프트웨어산업을 키울 수 없다"고 지적한 바 있습니다. (한겨레 신문, 2003.9.1. 보도) 정통부는 공익을 수호할 의무가 있는 것이지, 개별 사업자의 영리추구를 위하여 망국적인 전산환경을 초래할 것이 뻔한 인증기관의 제안을 받아들여서는 아니된다고 생각합니다. 따라서, "비용이 더 들고, 관리에 어려움이 있다"는 것은 MS 제품을 사용 안하는 자에게 인증역무 제공을 거절할 "정당한 사유"가 되기는 어려울 것입니다.
셋째, MS 전용 인증서처리 솔루션이 제공하는 보안사양과 보안수준을 구현하는 대안 기술이 현재로는 존재하지 않는다는 주장
이것은 사실과 다릅니다. 이점을 자세히 설명하겠습니다. 인증서를 사용한 거래가 현재의 솔루션에서 처리되는 구조를 은행 거래를 예로 들어 보면 다음과 같습니다.
- 은행 웹서버가 사용자 컴퓨터로 보내 온 양식에 사용자가 계좌번호, 금액, 보안카드 번호 등을 입력하고 "확인"버튼을 누른다.
- 입력된 값(정보)이 사용자 컴퓨터 내에 가동되는 ActiveX 콘트롤에 공급된다.
- ActiveX 콘트롤은 이 정보에 전자서명을 부착할 필요가 있는지를 판단하고, 그럴 필요가 있으면 인증서 암호를 사용자에게 요구하여 확보한 다음 전자서명을 부착한다. 이때 사용자의 개인인증서에 포함된 그의 잠금쇠(공개키)도 부착된다.
- 이렇게 모아진 정보를 웹서버가 보내온 잠금쇠(기관인증서에 포함되어 있는 공개키)로 잠근 다음, 투명하게 공개된 네트웍을 통하여(http 프로토콜을 사용) 암호화된 정보를 내보낸다.
- 암호화된 정보를 받은 웹서버는 자신이 보관하는 비밀키를 이용하여 암호를 풀고, 인증 서버에 접속하여 사용자가 보내온 인증서가 유효한지를 확인한 후, 요구된 작업(예를 들어, 계좌 이체)을 한다.
- 작업 결과를 담은 정보(이체 처리 내역)를 사용자의 공개키로 잠근 다음 네트웍을 통하여 암호화된 정보를 사용자에게 보낸다.
- 사용자의 컴퓨터는 받은 정보를 ActiveX 콘트롤에 공급하고, ActiveX 컨트롤은 사용자의 비밀키로 이 정보를 열어 사용자 화면에 보여준다.
이 과정에서 ActiveX 콘트롤이 수행하는 역할은 위 3, 4, 7 에서 필요한 작업을 사용자의 웹브라우저 속에서 처리하고 그 결과를 웹브라우저에 그려내는 "mini 응용프로그램", 즉 애플렛(applet)의 역할입니다. "애플렛"은 주어진 어떤 응용프로그램의 내부에서 특정 기능을 수행하여 그 응용프로그램의 기능성을 높이는 "부속 프로그램"입니다. 많이 알려진 애플렛으로는 자바 애플렛, 플래시 무비, 윈도즈 미디어 플레이어 애플렛 등입니다.
그러나 ActiveX 콘트롤은 원래는 MS사가 만든 비쥬얼 베이식스(Visual Basics)라는 개인용 컴퓨터 프로그램 개발도구의
하나로 등장한 소프트웨어 컴포넌트 기술이었습니다. 그 후 MS사가 자신의 브라우저(IE) 사양을 개조하면서 ActiveX
콘트롤을 통하여 기존에 데스크탑 프로그램에서만 쓰이던 윈도즈의 여러 소프트웨어 컴포넌트(예를들어, 풍부한 편집 기능을 제공하는
RichEdit, 엑셀과 같은 스프레드 시트 기능 등)을 웹브라우저 속으로 불러들일 수 있게 되었습니다. 이 방법을 사용하여
MS사는 경쟁사인 Sun Microsystems 사가 개발한 java applet과 비슷한 효과를 거둘 수 있게
됩니다. ActiveX 콘트롤을 이렇게 애플렛처럼 사용하는 MS사의 독특한
해법에
대하여 Wikipedia는 다음과 같이 평가하고 있습니다:
Microsoft later modified the Internet Explorer web browser to use [ActiveX Controls] to incorporate applet-like functionality into web pages. Because of that later use, ActiveX Controls have since been much derided in the mainstream and technical press for their ability to be used by unethical developers to create computer viruses, trojans and spyware infections.
그 후 MS사는 IE 웹브라우저를 개조하여 ActiveX 콘트롤을 통하여 애플렛과 비슷한 기능을 웹페이지에 구현하도록 하였다. ActiveX 콘트롤이 이런식으로 사용되었기 때문에 이 분야의 주류적 견해와 기술문헌에서 ActiveX는 많은 조롱을 받고 있는데, 그 이유는 악의적인 프로그래머가 이 방법으로 컴퓨터 바이러스, 트로이 목마, 스파이웨어 등으로 사용자의 컴퓨터를 감염시킬 수 있게 되었기 때문이다.
MS 사의 이러한 해법이 조롱과 비난을 받는 더 중요한 이유는, Sun 사가 개발한 자바 기술은 인터넷 콘텐츠가 사용자 컴퓨터의 하드웨어 설계구조(architecture)나 소프트웨어 운영 체제(OS) 또는 브라우저에 상관없이 두루 구현되어 정보의 막힘없는 소통 가능성을 열었음에 반하여, MS 사의 전략은 오로지 자신의 운영체제와 자신의 브라우저만이 처리할 수 있는 기술을 사용하여 자바 애플렛과 비슷한 결과를 거두게 한 다음, 윈도즈 운영체제의 시장지배력을 사용하여 ActiveX를 확산 시킴으로써 정보의 소통이 또다시 OS와 브라우저에 종속되도록 시도하(여 성공하)였기 때문입니다.
우리 공인인증서가 채택한 기술은 MS사의 이러한 독점 유지 및 정보 차단 전략에 철저히 봉사하는 것일 뿐 아니라, 심지어 국내 일부 은행은 위 6 과 7에 언급된 단계에서 암호화 하지 않은 정보를 그대로 네트웍으로 내보냄으로써 고객들의 송금, 계좌이체 내역, 잔고 등을 누구라도 큰 어려움 없이 인터넷 상에서 엿볼 수 있게까지 하고 있습니다.
[전자서명법 제19조 제1항과 제22조의2 제2항에 대한 논의 ... 준비 중]
5. 즉시 실행 가능한 대안들
현재의 솔루션과 같은 수준 또는 더 나은 수준의 보안을 확보할 수 있는 대안으로서 지금 당장 사용 가능한 것들은 다음과 같습니다.
자바 애플렛
ActiveX 라는 배타적
해법 대신에, 보편적 구현이 가능한 자바 애플렛을 사용하는 방법입니다. 자바애플렛이 사용자
컴퓨터의 웹브라우저에서 실행되는 구조는 간단합니다. 웹페이지 속에 자바 애플렛을 불러오라는 명령어가 발견되면 사용자 컴퓨터의 웹브라우저는 웹서버로부터 필요한 프로그램(java bytecode)을 내려받은 다음, 이 프로그램이 사용자 컴퓨터에서
실행됩니다. 즉, 위에 적은 3, 4, 7 의 단계에서 필요한 일을 수행할
프로그램을 웹서버가 실시간으로 사용자에게
제공하는 것입니다. 이렇게 내려받은 프로그램이 사용자의 컴퓨터에서 실행되는 환경은 매우 높은 수준의 보안이 확보된
환경입니다. 내려받은 프로그램은 컴퓨터에 설치되는 것이 아니고, 사용자 컴퓨터 안에 임시로 마련되는 가상의 컴퓨터(java
virtual machine, sandbox)에서 그 즉시 실행되며, 가상컴퓨터와 사용자 컴퓨터 간에는 여러
보안 장벽이 마련되어 사용자의 컴퓨터가 외부 프로그램으로 부터 보호되는 구조입니다. 반면에, ActiveX가
가지는 보안상 취약점에 대하여는 여기 참조.
이 방법이 가지는 장점은, 우선 탁월한 안전성(security)이 확보되고, 운영체제에 구애 받지 않고 범용이 가능하다는 점(cross-platform application), 사용자가 컴퓨터에 관리자 권한으로 어떤 프로그램도 설치(install)할 필요가 없다는 점입니다. 관리자 권한이 없는 일반 사용자도 자바 애플렛을 불러와서 실행할 수 있다는 점은, 한국의 전산환경에서는 선뜻 그 장점을 이해하기 어려울지 모르나, 제대로 관리된 전산 환경에서는 극소수의 전문 인원만이 관리자 권한으로 컴퓨터를 사용한다는 점을 이해하면, 매우 중요한 장점입니다. 예를 들어, 현재의 공인인증서를 착탈식 저장매체(플로피, usb memory stick 등)에 저장하여 외국에서 사용하고자 하는 경우, 그 나라의 학교나 회사 등 네트웍으로 관리되는 컴퓨터에서는 윈도즈 운영체제와 IE브라우저를 사용하더라도 우리의 공인인증서를 이용할 수는 없습니다. 왜냐하면, 인증서 사용을 위하여는 컴퓨터에 추가프로그램을 설치하여야 하는데, 네트웍 관리자가 이것을 함부로 허락할리 없기 때문입니다. 외국의 공항, 인터넷 카페, 기타 공공 장소에 제공된 컴퓨터는 우리 나라와 같이 아무나 관리자 권한으로 프로그램을 마구 깔고 지우고 하도록 방치된 경우가 거의 없습니다. 결국 우리 공인인증서를 사용하려면, 윈도즈가 탑재된 개인용 컴퓨터를 하나 마련하여 들고 다니는 수 밖에 없습니다.
자바 애플렛의 단점은, 애플렛을 내려받는데 약간의 시간(약 1, 2 초 가량)이 소요된다는 점과, 사용자 컴퓨터 내에 가상컴퓨터가 마련되는 동안 약간(1, 2초간) 기다려야 한다는 점 입니다. 그러나, 한국과 같이 "초고속" 인터넷 망이 널리 확산된 경우 내려받는 시간은 더 이상 문제가 되지 않고, 일단 가상컴퓨터가 한번 마련되고 나면, 컴퓨터를 끄지 않은 이상 즉시로 자바애플렛의 실행이 가능하므로, 사용 편의성에 큰 문제가 있다고 볼 수는 없습니다.
플래시
최근 어도비(Adobe)사에 인수된 매크로미디어(Macromedia)라는 회사가 개발한 플래시(Flash player)도 애플렛의 일종입니다. 그러나 자바 에플렛에 비하여 플래시는 내려 받아야 할 파일의 크기가 매우 작고, 플래시 플레이어 그 자체가 가상 컴퓨터역할을 하기 때문에 자바 가상컴퓨터(JVM)가 마련되는데 걸리는 시간이 필요없다는 장점이 있습니다. 흔히, 플래시는 동영상 등의 처리에 쓰이는 멀티미디어 프로그램으로 알려져 있으나, 자바 애플렛과 같이 광범한 프로그램 실행 기반으로 사용될 수가 있습니다(ActionScript). 위 3, 4, 7 의 단계에서 수행되어야 할 프로그램을 이진파일의 형태로 웹서버가 사용자 컴퓨터에 실시간으로 제공하고, 사용자의 웹브라우저는 이 파일을 내려받아 플래시 플레이어를 가상컴퓨터로 삼아 그 안에서 해당 프로그램을 즉시 실행하는 구조입니다.
플래시 역시 ActiveX 보다는 더 나은 안전성을 제공하고, 매킨토시, 리눅스 등 여러 운영체제에서 작동이 가능합니다. 그리고 이미 전 세계 인터넷 사용자(OS 구분 없이)의 98%가 플래시 플레이어를 설치해 두고 있을 뿐 아니라, 관리자 권한이 없는 일반 사용자가 자신의 개인용 파일시스템에 이것을 설치하는 구조이므로, 보안 위험을 최소화 하면서(즉, 시스템 파일에 대한 접근권한을 가질 필요 없이) 추가 설치 및 업그레이드가 가능하도록 되어 있습니다.
국내 보안업체는 이미 플래시와 자바 애플렛을 사용한 공인인증서 처리 솔루션 개발을 완료한 상태입니다.
- 이니텍 과 리아솔루션이 공동 개발한 플래시+자바애플렛 기반 솔루션
(2005.8.)
http://www.macmadang.com/html/features/features_view.php?n=549&p=1
브라우저 확장 플러그인
플러그인(plugin)
은 애플렛과 같이, 어떤 응용프로그램이 실행되는 맥락 하에서 그 응용프로그램 이용에
도움이 되는
특정한 부가적 기능을 수행하는 보조 프로그램
입니다. 때로는 확장(extension)이라 불리기도 하는데, 이 방법을
사용하면 주된 응용프로그램의 덩치를 줄이는 대신, 사용자마다 자신이 원하는 부가기능만을 선택적으로 추가하여 각자에게 적합한
이용편의성을 확보하게 되므로 각 개인이 컴퓨터의 리소스를 효율적으로 이용할 수 있게 됩니다. 특히 종속프로그램과
주프로그램간의 연락과 리소스 호출방법 및 규격을 제시하는 API가 투명하게 공개되어 있는 경우, 전 세계의 어떤 프로그래머더라도 자신이 생각해 낸 기발하고 독특한 부가기능을 수행하는 종속프로그램을 만들어 인터넷을 통하여 제공함으로써 주 프로그램 기능성의 무한한 확장이 가능하게 됩니다. 주응용프로그램의 소스코드와 정확하고 자세히 설명된 API가 완전히 공개된 파이어폭스 브라우저가 그 대표적인 예입니다. 공개소스에 기반한 파이어폭스 브라우저는 이처럼 자발적으로 형성되는
전세계의 개발자 공동체(developers' community)에 의하여 계속 변화, 발전해 나가게 되는
것입니다.
공인인증서 처리와 관련된 위 3, 4, 7 의 단계에서 행할 작업을 브라우저 내에서 수행하는 보조 프로그램(plugin)이 만들어 질 수 있음은 물론입니다. 그리고 이미 그러한 확장 플러그인은 국내 기술진이 개발을 완료한지 오래되었습니다.
- 소프트포럼, 윈도즈 기반에서 가동되는 파이어폭스 브라우저 플러그인(2005.1.)
- 소프트포럼, 리눅스 기반에서 가동되는 파이어폭스, 오페라 브라우저 플러그인(2005.5.)
- 소프트포럼, 리눅스에서 사용할 수 있는 공개 인증키 개발(2004.12.23.)
자바 애플렛이나 플래시의 경우와는 달리, 확장 플러그인은 그 설치파일을 사용자 컴퓨터에 설치하여야 하는 불편이 있긴하지만, 현재 사용되는 ActiveX 콘트롤과는 달리, 관리자 권한이 필요없이 일반 사용자의 개인 파일 공간에 프러그인을 설치하도록 되어 있어 보안 위험을 크게 줄인다는 차이점이 있습니다.
그리고 신한은행은 2002. 경부터 매킨토시 이용자를 위한 공인인증서 발급, 사용에 필요한 단독 프로그램(EzPlus)를 구비하여 실제로 사용하기 시작하였고, 지금도 사용하고 있습니다. EzPlus version 2.0
이 사건 민원신청이 언론에 보도된 후, 정보 통신부는 국정홍보실을 통하여 다음과 같은 해명을 공식발표하였습니다:
전자민원시스템의 경우, 인터넷을 통해 전송되는 개인정보 및 금융정보를 보호하기 위해 ▲암호화 통신 ▲키보드 해킹 방지 ▲바이러스 방지 등 보다 강화된 보안기술을 필요로 하나, 현재 공개 소프트웨어 기반에서 상용화된 보안제품이 없다.
키보드 해킹 방지, 바이러스 방지 용도의 응용프로그램 설치파일을 배포하는 것은 이 사안과는 아무 관련이 없는 문제일 뿐아니라, 그 두 프로그램을 설치하도록 요구하는 것은 마치 '약을 건네 주면서 더 큰 병에 대한 잠재적 원인까지 함께 제공'하는 것이나 마찬가지 입니다. 이 프로그램들을 설치하려면 관리자 권한으로 컴퓨터를 사용해야하고, 이것은 사용자 컴퓨터를 더 큰 위험에 노출 시키는 결과를 초래합니다. 더욱이, 이런 프로그램의 배포를 위하여 ActiveX 콘트롤을 사용하여야 할 하등의 이유도 없습니다. 문제는 암호화 통신에 관한 것인데, 전자민원이건, 은행거래건, 공인인증서 발급이건, 현재는 모두 ActiveX 콘트롤을 사용하고 있지만, 이 세가지 모두 지금보다 더 나은 보안 수준을 확보하면서 브라우저나 OS에 의존하지 않는 기술적 대안이 이미 개발되었거나, 상용화 단계에 있은지 오래 되었습니다. 따라서 정통부의 공식 해명은 기초적인 사실부터 틀린 것입니다. 이렇게 부정확한 정보에 근거하여 업무를 수행하는 인력이 우리 전산체계의 운명을 좌우하는 권한을 행사한다는 것은 국민으로서 일말의 불안감을 가질 수도 있는 일이라 하겠습니다.
6. 위법한 현 상황을 시정하는 방법
크게 보아 두가지가 있습니다.
첫째, 현재의 솔루션에 새로운 솔루션을 추가하는 방법
기존의 방법을 그대로 사용하기를 원하는 이용자는 아무런 변화를 느낄 이유도, 필요도 없습니다. 인터넷 거래도
아무런 변화 없이 계속 될 것입니다. 다만, 위에 설명한 세가지 기술 대안 중 하나를 추가 솔루션으로 인증기관이 이용자에게
제공하게 되는데, 이것 역시 매우 간단합니다. 플래시를 사용한 솔루션이 추가되는 경우를 예로 들어
설명하겠습니다. 현재 공인인증기관의 홈페이지에는 발급신청
버튼이 하나 뿐이지만, 추가 솔루션이 제공되면
발급신청 버튼이
두개로 늘어납니다. 그리고 그 각 버튼에 다음과 같은 간략한 설명이 제시될 것입니다:
| 발급신청1 (ActiveX사용) |
| 발급신청2 (플래시 사용) |
인증서발급 신청자가 첫번째 버튼을 누르는 경우는 지금과 완전히 동일한 과정이 진행됩니다. ActiveX 브라우저 플러그인을 웹페이지에서 내려받아, 관리자 권한을 가지고 이것을 사용자 컴퓨터에 설치하고, 그 설치가 끝나기를 기다린 다음 (약 5-10초 소요), 그 다음 단계로 진행합니다. 두번째 버튼을 선택하는 경우 신청절차는 훨씬 간단합니다. 우리나라 컴퓨터의 99%에는 이미 플래시 플레이어가 설치되어 있으므로, 웹서버에서 보내오는 플래시 파일이 사용자의 플래시 플레이어에서 즉시 (약 1초 소요) 실행되고, 성명, 주민등록번호 등을 입력할 칸이 화면에 뜨게 됩니다. 두번째 버튼은 리눅스, 매킨토시 사용자는 물론이고 윈도즈 사용자도 브라우저에 상관없이 누구나 성공적으로 인증서 발급절차를 완료할 수 있는 버튼이 되는 것입니다.
윈도즈 기반에서 IE브라우저를 사용해오신 분들은 첫번째 버튼을 만족스럽게 선택할 것입니다. MS 제품을 사용하지 않거나, MS 제품을 사용하더라도 ActiveX 콘트롤이 가지는 보안상의 취약점을 염려하는 이용자는 두번째 버튼을 클릭할 것입니다.
이용자로서는 이처럼 어떠한 추가 조치를 하거나 소프트웨어를 내려받아 설치할 필요가 없는 반면(플래시 플레이어가 이미 설치되어 있다고 가정), 웹서버로서는 약간의 변경이 필요합니다. 이용자가 플래시를 선택하여 절차가 진행될 때 이를 처리하는 소프트웨어 스크립트를 서버에 마련하여야 하기 때문입니다. 그러나 이 작업은 현재 여섯 군데의 인증기관 서버에서만 필요한 것이고, 그 일이 그다지 복잡한 것도 아닙니다. 제대로 훈련된 기술인력이 노력을 집중한다면, 한 두 달여 만에 모든 작업이 이루어질 수 있는 정도의 업무량에 불과합니다.
둘째, 현재의 솔루션을 새로운 솔루션으로 대체하는 방법
이 경우에도 이용자에게는 어떠한 불편이나 비용이 초래되는 것도 아닙니다. 컴퓨터를 잘 모르는 이용자는 변화가 있는지 조차 못 느낄 것입니다. 발급신청 버튼 마저도 지금 그 모습 그대로 유지하면 됩니다. 다만 인증기관의 서버에 위에서 언급한 발급신청2 의 경우처럼 플래시를 사용하여 서버로 전달되어 오는 정보를 처리하는데 필요한 서버사이드 스크립트를 준비하면 되는 것입니다.
이 두가지 방법 중 하나는 전자서명법을 준수하기 위하여 공인인증기관이 지금 즉시 채택하여야 할 의무가 있는 사항입니다.
7. 정보통신부 장관의 책임와 의무
전자서명법은
매우 혁신적이고, 야심찬 내용을 담은 법입니다. 장차 대부분의 재산적, 비재산적 거래와 인간의 상호작용이 적어도
일부는 인터넷을 통하여 이루어질 가능성을 염두에 두고, 그 기반을 준비하고 초석을 놓는 의미에서 공인인증제도를
마련하는 법입니다. 그러나 인증 제도가 지금처럼 잘못 자리잡으면, 얼마 가지 않아 MS 제품을 사용하지 않는
국민은 정체불명의 "불가촉 천민"으로 전락하여 인터넷 상을 떠돌게 될 것입니다. 우리의 전산망 전반과 정보통신
소프트웨어 산업이 건강하게, 독립적으로 성장할 가능성도 영영 말살 됩니다. 이러한 위험천만한 결과를 예방하고자
전자서명법은 정통부 장관에게 매우 강력한 권한을 부여하여, 그로 하여금 우리 전산 환경에 대한 중립적 감시자
역할을 맡기고
있습니다.
전자서명법 제11조는, 공인인증기관이 인증역무의 제공을 거부하거나 가입자 또는 인증역무 이용자를 부당하게 차별한 경우
에 정통부 장관은 기간을 정하여 시정조치를 명할 수 있다
고 되어 있고;
제12조는 인증기관이 이러한 시정명령을 정당한 사유없이 이행하지 아니한 경우
에는 정통부 장관은 인증업무의 전부 또는 일부의 정지를 명하거나 지정을 취소할 수 있다
고 되어 있습니다.
그리고 제34조는, 정당한 사유없이 인증역무의 제공을 거부하거나 가입자 또는 이용자를 부당하게 차별한 자
에 대하여는
정통부 장관이 과태료를 부과하도록 규정되어 있습니다.
국민의 위임을 받은 입법자가 이러한 규정들을 전자서명법에 둔 이유는 바로 지금과 같은 상황이 올 것을 우려하였기 때문입니다.
전산망을 통하여 제공되는 정보와 서비스에의 접근이 부당하게 거절되어서는 안된다는 점은 관련 법률 곳곳에 거듭 강조되는 바입니다. 예를 들어, 정보화 촉진 기본법 제16조의2 제1항은 정부는 정보통신망에 대한 자유로운 접근과 이용을 보장하고 지역적·경제적 차별이 없는 균등한 조건의 보편적 역무가 제공될 수 있도록 필요한 시책을 강구하여야 한다
고 규정하고 있습니다. (이외에도 정보화 촉진 기본법 제3조 제3호, 제5조 제8호, 제13조; 정보격차 해소에 관한 법률 제3조, 제7조, 제8조, 제9조, 제16조 등 참조) 이 규정들의 혜택이 MS 제품 사용자에게만 베풀어져야 한다고 믿는 정통부 관계자는 없을 것입니다. MS고객 전용서비스가 관련 법에서 말하는 보편적 역무
일 수는 없습니다.
인증기관이 오로지 자신의 이윤을 극대화하기 위하여, 존재하지도 않는 기술적 어려움
을 과장하고, 사용자가 많지 않다는
이유로 MS 고객이 아닌 자들에 대한 인증역무 제공을 거부하는 지금의 상황은 전산망국으로 가는 벗어날 수 없는 궤도에 갇혀
있는 형국입니다. 기술적 어려움이 있다는 이들 업체의 주장은 사실과 다릅니다. 1997-1998 당시에는 Netscape
브라우저 용 플러그인을 제공하였습니다. 지금 이들 업체들이 IE 브라우저 외의 다른 브라우저에 대한 지원을 중단한 이유는 기술적 이유가 아니라 사업상의 이유
로 선택한 결정입니다. 현재 우리 보안 업체들은 주요 브라우저에 대한 인증서 처리
솔루션을 이미 가지고 있습니다. 어느 인증기관도 이 기술을 구매하지 않기 때문에 사용되지 않을 뿐, 현실적으로 구현이 어렵다
는 인증업체의 주장은 거짓입니다.
이러한 위법하고 부도덕한 상황이 지난 몇년 간 계속되었음에도 정통부 장관은 인증기관에 대한 아무런 시정명령도 발동하지 않고, 아무런 조치도 취한 바 없습니다. 우리의 소프트웨어 산업이 크게 위축되고, 개인용 컴퓨터 OS 시장의 MS 점유율이 세계 최고 수준인 99.4%에 까지 이르게 된데에는 정통부 장관의 이러한 직무 유기가 그 결정적인 원인을 제공하였다고 생각합니다.
어느 누구도 정통부 관계자의 선의(善意)와 우리 전산산업 육성에 대한 열정을 의심하지 않습니다. 그러나 지금처럼 위법한 상황이 앞으로도 계속 방치된다면, 업체와의 유착이나 부패에 대한 근거없는 의혹이 제기되어 참여정부의 도덕성에 상처가 가는 불행한 사태가 올까 염려됩니다.
8. 장기적 계획
이상 제기한 점들은 지금까지 너무 오래 계속된 위법 상황을 시급히 시정하고, 고사(枯死) 상태에 있는 우리의 소프트웨어 산업을 조금이나마 소생시키는데 필요한 응급처방
을 투여하는 수단입니다. 소프트웨어는 계속 이용하고, 가꾸어 나가야 유지되는 것입니다. 이용자가 없어지면 아무리 기술적으로 우월한 소프트웨어라도 사라지게 마련입니다. 온 국민의 컴퓨터에 ActiveX 컨트롤을 하나씩 설치하려는 정통부의 시도는 자살행위에 다름 아닙니다.
그러나, 응급처방을 투여한 다음에는 건강회복에 필요한 재활치료가 이루어져야 합니다. 올바른 정보화 정책을 마련하고, 이를 분명히 실천하고, 그 성과를 꼼꼼히 점검하는 행정 시스템이 필요한 부분입니다. 정보격차 해소에 관한 법률 제3조는 국가 및 지방자치단체는 ... 모든 국민이 정보통신서비스에 자유롭게 접근하고 이를 이용할 수 있도록 필요한 시책을 강구하여야 한다
고 되어 있고, 제16조 제1항은 정부는 모든 국민이 정보통신서비스에 자유롭게 접근하고 이를 이용하여 삶의 질을 향상할 수 있도록 지원하기 위하여 한국정보문화진흥원을 설립한다
고 되어 있으며, 이에 따라 2003.1. 설립된 정보문화진흥원은 현재 연 예산 1,130억을 사용하고 있습니다(웹 페이지에 2006년도 예산은 113,193천원
이라고 되어 있으나, 이는 오기인 것으로 보입니다). 그리고 정보화 촉진 기본법 제5조 제3항에 의하면, 정부는 정보통신 표준화의 촉진
을 위한 기본 계획을 마련하고 추진할 의무를 지고 있습니다. 그리고 소프트웨어산업 진흥법 제12조는 정보통신부장관은 소프트웨어의 효율적 개발 및 품질향상과 호환성 확보 등을 위하여 소프트웨어의 표준화를 추진
하고, 이를 위하여 표준화 활동에 필요한 예산을 지원할 수 있다
고 되어 있습니다. 이 법에 따라
한국소프트웨어진흥원이 1998에 설립되었고, 2006년 기준으로 연간 2,550억원의 예산을 사용하며 활동하고 있습니다.
이러한 여러 법 규정에서 말하는 표준화
가 MS전용화를 뜻하는 것이 아님은 분명할 것입니다. 이미 마련되어 있는 조직과 예산(합계 3,680억/년) 그리고 매우 전향적인 법제의 뒷받침을 받는 현 상황이라면, 공인인증서 처리 솔루션과 관련하여 다음과 같은 계획을 신속하게 검토, 확정, 실행하는데 별 어려움이 없을 것으로 생각합니다.
인터넷 금융거래 표준 사양 (Electronic banking internet communication standard)
자바 또는 플래시 애플렛, 브라우저 플러그인 등의 해법은 지금까지 부당하게 차별 받아 왔던 일부 국민들에게 인터넷 이용의 길을
공평하게 열어 준다는 점, MS사의 기술에 철저히 종속되어 하청업자
수준으로 전락해 온 우리의 소프트웨어 산업에 재활의
길을 터 준다는 점, 공정거래법과 WTO 조약 상 정부가 부담하는 의무에 반하는 현재의 위법 상황을 신속히 시정하는 길이 된다는
점 등에 비추어 보아, 반드시 취해져야 할 조치임은 분명합니다. 그러나 프로그램 개발이 지금과 같이 업체의 통제 하에 있게
되는 업체 제공 해법(proprietary solution)
이라는 점은 여전히 문제로 남습니다. 또한, 위 해법 중 플러그인의 경우에는 컴퓨터 하드웨어 설계구조와 운영체제 그리고 브라우저 별로 각각 그 프로그램을 컴파일하고 관리해야 하는 부담이 있고, 계속 변화하는 컴퓨터와 브라우저의 사양에 상응하는 새로운 버전의 배포를 해당 업체에 의존하여야 하는 구조 역시 지금과 어느정도는 공통점이 있습니다.
이러한 문제점을 근본적으로 해결하고, 공개소프트웨어 진흥정책의 초석을 놓는 작업은 바로 인증서처리 및 인증서를 사용한 은행거래가 수행되는 각 단계에서 이루어 져야할 작업들의 자세한 표준 규격(표준 사양, 표준 프로토콜)을 정하여 이것을 공표하는 것입니다. 그렇게 되면 국내 외를 막론하고 어떤 프로그래머이든지 이 규격에 맞추어 애플렛이건 플러그인이건 클라이언트 용 솔루션을 독자적으로 개발 할 수 있고, 이렇게 개발된 소프트 웨어는 어느 인증기관이나 어느 은행에서건 가동 될 수 있습니다. 서버측 솔루션도 마찬가지 입니다. MS 전용 기술을 사용한 솔루션 개발업체도 동등하고 공평한 조건에서 서버용이건 클라이언트 용이건, 프로그램 개발 경쟁에 참여하게 되고, 인증기관이나 은행으로서는 이러한 전용 솔루션과 범용솔루션을 병행하여 자신의 고객들에게 제공하기로 선택할 수도 있고, 범용 솔루션 하나로 통합하여 제공하기로 선택할 수도 있는 것입니다. 이 양자 사이의 선택은 각 은행이나 인증 기관의 정당한 사업 결정
의 몫으로 돌리면 됩니다. 이것이 공정한 경쟁이고, 이것이 시장의 기능입니다.
MS전용 솔루션 만이 존재하고, 인증서처리나 인터넷 금융거래에 관한 아무런 표준사양도 없는 현 상황에서는 은행 등으로부터 계약을 따낸 업체 이외에는 누구도 어쩔 도리가 없습니다. 범용솔루션이 오픈소스 기반에서 개발될 가능성이 현재로는 원천봉쇄되어 있는 셈입니다.
- http://openlook.org/blog/1084
- http://www.ebics-zka.de/english/ (은행 간 혹은 법인 클라이언트를 위한(B2B) 표준); http://openhbci.sourceforge.net/;
- http://www.aquamaniac.de/aqbanking/ (HBCI를 구현한 라이브러리 및 응용프로그램 리소스) 등 참조.
