액티브X 문제는 공인인증서에서 특히 심각하다. 직접 돈을 거래하는데 사용되기 때문이다. 게다가 웹 표준화 단체인 오픈 웹의 금융결제원을 상대로 한 거액 소송 덕분에 액티브X로 만든 공인인증서를 다른 기술로 대체하자는 목소리 또한 높아졌다. 특집 2부에서는 공인인증서 대체 기술로 부각되고 있는 기술 중 자바 공인인증서에 대해 간단히 알아본다.

지금까지 전자결제나 공인인증서 처리에는 액티브X 기술이 독점적으로 사용되어 왔다. 하지만 마이크로소프트(이하 MS)의 독점 기술인 액티브X는 다른 기종의 웹브라우저나 다른 OS 플랫폼에서는 전혀 동작하지 않는다. 예전부터 리눅스나 매킨토시 등 다른 운영체제를 사용하는 사용자 모임에서는 이 문제를 끊임없이 제기해왔다.

급기야 노무현 대통령에게 리눅스 선물하기 모임(줄여서 ‘노리추’라고도 함)이 결성되기 까지 했다. 이 모임은 액티브X 일변도인 인터넷 환경에서 다른 플랫폼을 사용하는 것이 얼마나 불편한지를 정부에 호소하기 위해 2005년 4월 22일 국민 참여 수석을 통해 리눅스가 설치된 컴퓨터를 대통령에게 전달하기도 했다.

이런 노력들이 있었음에도 불구하고 대다수의 윈도우 사용자와 정부는 큰 반응을 보이지 않았다.

공인인증서 구현 기술들에 대한 고찰

그런데, 왜 최근 들어서 갑자기 액티브X 이외의 다른 기술로 공인인증서를 처리하는 것에 대한 관심이 급부상하고 있는 것일까? 그 이유는 MS가 윈도우 비스타를 출시하면서 스스로가 제안한 액티브X를 부정했기 때문이다. 더 정확히 말하면 IE7에서 제공하는 보호모드 기능 때문이다.

IE7의 보호모드 기능은 [Windows]나 [Program Files] 등의 시스템 폴더에 파일이 저장되지 않도록 차단하는 기능이다. 그렇다고 시스템 폴더로의 접근이 완전히 차단된 것은 아니다.

일단 IE7을 실행하면 표준 사용자 권한에서 실행된다. 만약 사용자가 IE7을 통해 합법적 시스템 폴더의 접근을 시도할 경우 관리자 권한을 획득하기 위해 윈도우에 권한 상승을 요청하여 사용자의 확인을 받게 하면 접근할 수 있다.

MS에서 보호모드 기능을 제공하는 이유는 액티브X가 상당히 편리한 웹 클라이언트 환경이지만, 보안상 취약한 부분을 내제하고 있기 때문이다. 액티브X를 악용하면 PC에 개인 정보가 노출될 수 있다.

바이러스가 유포되고 원하지 않는 플러그인들이 설치되기도 하며, 컴퓨터 속도를 떨어뜨리는 ‘그레이웨어’의 유포 등 액티브X의 사용자에게 정신적, 물리적, 경제적 피해를 주는 사례가 많았다. 이러한 이유들 때문에 윈도우 비스타(IE 7)의 개발 스펙에 보호모드 기능을 추가한 것이다.

또 다른 이유로 비 MS나 비 IE 사용자들의 불편함이 주무부처에 공감대를 얻은 것으로 해석된다. 물론 그 동안 이런 민원들에 대한 적극적인 응대는 없었다. 앞서 언급한 노리추 사건과 지난 2007년 1월 23일 대한민국 전자정부 웹페이지 국제 표준화 운동을 주도하고 있는 오픈웹(http://openweb.or.kr)이 금융결제원을 상대로 4억 1,500만원의 손해배상 청구한 사건도 있었다.

이러한 일련의 사건과 현상들이 종합되어 개발자가 아닌 사람들까지도 액티브X에 대한 관심을 가지게 되었다. 그 결과 운영체제나 브라우저에 독립적인 공인인증서 처리 애플리케이션이 시대적인 요구로 자리 잡게 된 것이다. 한국정보보호진흥원(이하 KISA)에서는 여러 대안 플랫폼 중 자바 플랫폼을 이용하여 공인인증서를 만드는데 대한 기술을 검토하고 있다.

오픈웹 소송과 자바 공인인증서

특집 2부는 자바로 공인인증서를 만들기 위해 필요한 기술과 해결 과제 등의 기술 쟁점을 소개하고 있다. 대체 왜 이런 복잡하고 어려운 기술에 대해 설명하고 있는 것일까? 그것에 대해 이해하기 위해 먼저 오픈웹 소송 과정부터 살펴보자. 액티브X 문제가 지속적으로 제기되어 왔지만 오랜 시간동안 그저 산발적이고 미약한 목소리들 탓에 큰 성과를 거둔 적은 별로 없었다. 그러다가 비스타 발표와 맞물려 웹 표준화 단체인 오픈웹(www.openweb.or.kr)이 심지에 불을 붙이며 액티브X, 그중에서도 공인인증서 문제에 불이 붙었다. 오픈웹의 소송 내용은 금융결제원(이하 금결원)이 특정 운영체제와 브라우저에서만 실행할 수 있는 공인인증서를 제공함으로써 윈도우와 IE를 사용하지 않는 사용자들을 차별했다는 내용이 주였다. 액티브X로 만들어진 공인인증서를 사용하고 있는 탓이다. 이러한 차별을 통해 그동안 피해를 입었다고 주장하는 83명의 원고인단과 함께 금결원을 상대로 손해배상 청구 소송을 한 것이다. 3%를 밑도는 소수 운영체제나 브라우저를 쓰는 사람들은 대한민국에서 인터넷 뱅킹조차 할 수 없도록 만들었으니 당연한 일일 터다. 인증서와 전자서명 시스템 잇따른 소송과 반발 그런데 오픈웹이 깃발을 들어 올리자 여기저기서 또 다른 목소리들이 터져 나왔다. 금결원이 그동안 특정 OS와 브라우저만 지원하는 인증서를 강요한 탓에 자신들이 범용적으로 사용할 수 있도록 개발한 공인인증서 소프트웨어를 사용하지 못하여 경제적 손실을 입었다며 한 결제 대행 서비스 업체도 소송 의사를 밝혔다. 더불어 오픈웹 소송 결과가 긍정적으로 진행되어가자 이번에는 아예 금결원은 공인인증 기관으로서의 자격이 없다며 공인인증기관 지정 취소 요구 소송을 준비하고 있다. 금결원이 은행들의 필요에 따라 만들어졌으며 은행 임원들이 이사진으로 구성된 금결원이 공인인증 기관으로 활동하는 것에 문제가 있다는 것이 오픈웹의 주장이다. 또, 소송 과정에서 금결원은 은행의 사소한 추가비용 발생 등을 이유로 IE 이외의 브라우저 사용자를 위한 공인인증 소프트웨어 제공을 거부하는 등 공인인증기관으로서의 역할을 충실히 하지 않고 있다는 점도 이유로 들고 있다. 이런 이유로 오픈웹은 6월경에 공인인증기관 지정을 담당하는 정보통신부를 상대로 금결원에 대한 공인인증 기관 지정의 취소를 요구하는 행정 소송을 제기할 방침이란다. 공인인증서 문제 자바로 해결하자 오픈웹 소송으로 액티브X 공인인증서 문제가 주목을 받자 한국정보보호진흥원(이하 KISA)이 발 벗고 나섰다. KISA는 지난 2월부터 관련 전분가들과 함께 범용적으로 사용할 수 있는 공인인증서를 만들기 위한 방안을 모색하고 있다. 이미 몇 차례 이 문제로 회의를 가진 끝에 내린 결론은 여러 방법 중 해외에서도 오픈소스를 통해 서비스를 구현하고 있는 자바가 가장 유력한 기술로 인정되고 있다. 자바는 JRE(Java runtime environment)만 설치되어 있는 환경이면 OS와 브라우저를 가리지 않고 지원한다. 반면에 기존의 액티브X 윈도우 계열의 OS와 IE에서만 작동하는 기술이기 때문에 비MS 계열의 PC 환경에서는 사용이 불가능한 상태이다. 물론, 자바를 이용한 공인인증 서비스 구현이 하루아침에 될 일은 아니다. 이런 서비스가 구현되려면 먼저 다양한 사용자 환경에 대한 지원과 국제 표준을 준용한 인증서 관리 기능 지원 여부, 국제 및 국내 표준 알고리즘(SEED 알고리즘)을 이용한 전자서명 생성과 검증, 암복호화 기능 지원, 스마트카드와 USB 보안토큰 장치 지원 등이 필요하다. 최근 KISA와 관련 전문가들은 자바의 보안성과 확장성을 중심으로 기술적인 검토를 하고 있으며, 비스타와의 호환성 등 여러 가지 문제에 대한 해결책도 모색 중이다. 이미 해외의 몇 개 나라에서는 자바를 이용하여 공인인증 서비스를 구현하고 있기도 하다. KISA와 전문가들의 노력, 사회의 관심 그리고 금융기관의 바른 의식이 하나가 되어 조만간 자바 공인인증 서비스를 만날 수 있게 되기를 바란다.

기술적 쟁점

사실 자바 공인인증서 처리 애플리케이션은 스페인과 미국, 독일, 덴마크, 핀란드, 대만 등 많은 국가에서 채택하고 있다. 하지만 국가마다 환경이 다르고, 무엇보다도 공인인증서 처리는 주로 금융 결제 및 인증과 같이 중요하고 민감한 거래에 사용된다. 때문에 개인의 권익을 최대한 보장 받을 수 있도록 안정성을 보장하는 기술검토가 필요하다.

여기에서는 자바로 공인인증서 처리 애플리케이션을 만들기 위해 고려해야 하는 기술 쟁점들에 대해 알아본다.

기술적 쟁점 1 – JRE의 비용
자바는 반 컴파일 + 반 인터프리터(half-compiled and half-interpreted) 언어다. 때문에 런타임에 자바의 실행을 지원하는 환경이 갖추어져 있어야 한다. 이 환경을 JRE(Java Runtime Environment)라고 하는데, 자바 공인인증서를 처리하려면 JRE가 반드시 설치되어 있어야 한다. 그렇다면 JRE를 설치하면 될 문제다. 하지만 JRE는 몇 가지 문제점을 가지고 있다.

●설치비용
네트워크로 JRE 설치 파일을 다운 받아 설치가 완료되기까지 작게는 수분 길게는 수십 분 이상의 시간적 비용이 따른다. 물론 이 설치는 한번만 해주면 된다. 또한, 설치 시 엔드 유저에게 낯선 몇 번의 클릭을 해야만 한다.

●JRE의 호환성
호환성은 다시 버전 별 호환성과 운영체제별 호환성으로 나눌 수 있다. 버전 별 호환성은 특정 상위 버전으로 설치를 권장하면 된다. 문제는 운영체제 별 호환성이다. 현재 썬마이크로시스템즈(이하 썬)에서 제공하는 공식 JRE(http://java.sun.com/)는 윈도우와 솔라리스, 리눅스 밖에 없다.

물론 IBM이나 애플 등 여러 OS 벤더들은 각자의 운영체제에 동작하는 JRE를 개발하고 배포한다. 하지만, 운영체제의 JRE 지원은 반드시 보장되는 것이 아니며, 운영체제에서 동작하는 JRE의 호환성도 확보되어야 한다.

하지만 애초에 자바는 WORA(Write Once, Run Anywhere)를 모토로 하는 언어이기 때문에 문제될 게 없으나 벤더의 표준화에 대한 보증이 담보되어야한다.

기술적 쟁점 2 – 자바 역공학의 문제
앞서 설명한대로 자바는 반 컴파일과 반 인터프리터 언어이기 때문에 자바는 컴파일 하기도 인터프리트하기도 용이한 언어다. 대부분의 경우 이런 자바의 특징은 장점이다.

그런데 이 장점은 반대로 역공학 하기 쉽다는 단점이 되기도 한다. 소스코드를 컴파일하면 곧바로 기계어로 실행할 수 있는 바이너리코드가 생성되는 것이 아니라, JVM이 실행하기 쉬운 바이트코드로 생성되기 때문이다.

현재 바이트 코드 to 소스코드로 역컴파일할 수 있는 툴들은 많이 나와 있는 상태다. 상황이 이러하니 자바 공인인증서 처리 모듈을 만들더라도 쉽게 그 소스를 볼 수 있게 되는 셈이다. 그렇다고 자바로 만들면 전부 역컴파일 된다고 생각할 필요는 없다. 암호화/복호화를 처리하는 코드는 조금의 노력만 투자한다면 쉽게 찾아볼 수 있기 때문이다.

또한, 우리나라에서 사용하는 공식 암호화 알고리즘이 SEED와 3-DES라는 것도 쉽게 알 수 있다(이 문서만 봐도 알 수 있지 않은가?). 문제는 암호화 알고리즘이 무엇이고 코드가 어떻다는데 있지 않다.

일단 PKI(Public Key Infrastructure) 기반의 암호화 및 인증 처리는 알고리즘이 중요한 게 아니라 개인키가 보호되는데 있다. 개인키 정보가 있는 인증서를 확보하지 못 한다면 알고리즘을 알아도 아무런 소용이 없다. 뿐만 아니라 자바 기술에서 역컴파일러의 발전만 있었던 게 아니라 난독기(obfuscator)도 발전했다.

그 덕분에 문자열 인코딩이나 제어흐름을 변경하는 정도의 기능으로도 충분히 역컴파일된 코드를 읽기 힘든 수준의 난독성으로 보장할 수 있다(물론 인내심이 강한 사람에겐 못 당하지만 말이다).

또, 역 컴파일의 문제가 자바만의 문제는 아니다. 액티브X도 역 컴파일의 위험에서 자유로울 수 없는 탓이다. 컴파일되어 배포되는 액티브X 코드도 어셈블리어로 역 컴파일 될 수 있기 때문이다. 어셈블리어를 가독성 높은 고급언어인 자바처럼 쉽게 읽는 사람은 많지 않지만 액티브X도 완벽히 로직을 은닉한다고 할 수 없는 셈이다.

기술적 쟁점 3 – 클래스 바꿔치기
지금까지의 문제는 나름대로 심각하지 않거나 대안이 있다. 하지만 이제부터의 문제는 좀 더 심각한 편이다.

자바 애플릿은 수행속도를 높이기 위해 매번 실행 시 마다 서버에서 jar 파일을 다운 받아 실행하지 않고 다운받은 jar 파일을 로컬 캐시에 저장해둔다. 캐시 된 jar가 저장될 위치는 Windows의 경우 [제어판] → [자바] → [일반] → [임시 인터넷 파일] → [설정]에서 확인할 수 있다.

물론 실행시마다 서버에서 다운로드를 받을 수도 있지만 인증서 처리 같이 사이즈가 큰 코드는 이 방식을 채택할 경우 시간적 비용 부담이 커진다.

캐시 디렉토리에 있는 jar 파일의 압축을 풀면 공격자가 주요 클래스를 자신이 만든 다른 클래스로 바꿔치기 할 수 있다. 만일 바꿔치기한 클래스가 동일한 로직을 수행하면서 아이디와 패스워드, 인증서 텍스트, 주민등록 번호 등을 공격자의 컴퓨터로 저장한다면 그 원래 사용자가 경제적으로 막대한 피해를 입게 될 것은 당연한 일이다.

이때 보안을 위해 Signed Applet을 사용한다 하더라도 큰 도움이 되지 않는다. Signed Applet은 Applet을 실행할 때 인증처리만 할 뿐이지 jar 파일의 변경을 감지하지는 못하기 때문에 바꿔치기 된 클래스를 그대로 실행할 수 있다. 참고로, 이 사실은 금융결제원 전자인증센터에서 증명되었다.

이 취약점은 자바 자체로는 해결하기 어려운 문제이다. CRC 처리를 한다던가, jar 파일에 변조를 감지하도록 sign을 한다던가, 특정 주요 클래스를 캐시하지 않고 동적 로딩 하는 방법도 생각해봤다.

하지만 ‘클래스 바꿔 치기’ 공격은 자바로 구현된 어떤 클래스에서도 시도할 수 있기 때문에 자바의 문제를 해결하는 자바 클래스는 동일한 문제를 해결할 수 없었다. 이 문제도 약간의 테크닉을 통해 해결할 수 있을 것 같다. 필자가 생각해둔 테크닉이 있지만 이 글에서 표현할 수는 없어 이 정도로 밝혀두겠다.

앞에서도 설명했지만, 이 부분도 액티브X에서 완벽히 해결된 사항이 아니다. 필자는 윈도우 실행파일을 역 어셈블하여 사용 기간이 제한된 셰어웨어의 만료일을 체크하지 않도록 해당 코드를 JUMP 시켰던 동료를 본 적이 있다.

액티브X도 변조가 가능하다는 얘기다. 문제는 자바 클래스를 변조해 바꿀 수 있는 사람보다 액티브X의 바이너리를 변조할 수 있는 사람이 압도적으로 적다는데 있다.

기술적 쟁점 4 – PKCS#11 지원 문제
자바에서는 암/복호화 처리를 위해 JCA(Java Cryptography Architecture)와 JCE(Java Cryptography Extension)를 정의하고 있다. JCA는 java.security 패키지에 있으며, 암호화 처리를 위한 메커니즘과 구조, 인터페이스, 팩토리 등을 정의하고 있다.

암호화 처리는 상당히 다양한 알고리즘을 사용할 수 있어서(혹은 어떠한 알고리즘을 사용하는지 알 수 없어서) SPI(Service Provider Interface)를 이용하고 있다. 왜냐하면 자바는 사용자가 사용할 알고리즘을 알 수 없고 사용자가 사용할 수 있는 모든 알고리즘을 제공할 수 없기 때문이다.

그래서 JCA는 SPI의 프로바이더를 이용하여 사용자가 사용할 암호화 방식을 등록/선택하게 하므로 어떤 알고리즘이던지 사용할 수 있는 틀을 제공한다.

<그림 1> JCA와 SPI를 통해 제공되는 서비스 관계

JCE는 java.crypto 패키지에 있으며, JCA의 확장으로 1.2 버전까지는 미국의 수출제약법령(U.S. export control regulations)에 의해 미국과 캐나다 내에서만 사용할 수 있었다. 그러나 JCE 1.2.2 부터는 제한적인 상황에서 미국과 캐나 다 이외 지역에서도 사용할 수 있게 되었다.

여하튼, JCE는 Cipher와 MAC(Message Authentication Code), Key Generation, Key Agreement 등 실제적인 암호화 처리를 제공한다. 보다 자세한 설명은 자바서비스넷의 이인영님이 게시한 Java Security와 Cryptography Architecture 문서(http://www.javastudy.co.kr/docs/lec_java/security/JAVASecurity.html)를 참조하길 바란다. 따라서 JCA와 JCE의 기능은 각각 <그림 2>와 같다.

<그림 2> 사용자 애플리케이션이 JCA와 JCE를 사용하는 관계

PKCS는 RSA 사의 연구실에서 주관하여 정의한 공개키 암호화 표준(Public Key Crpytography Standard)이다. 이 표준은 공개키 암호화를 위한 각종 방식을 정의하고 있는데 PKCS#1 부터 PKCS#15 까지 15 종류의 표준이 있다. PKCS#11은 11번째 표준으로서 암호화 토큰 인터페이스 표준을 정의하고 있다.

자바SE 5.0에서 자바 플랫폼에서 네이티브 PKCS#11 토큰의 통합을 편리하게 하기 위해 Sun PKCS#11 프로바이더를 추가하였다. 이 프로바이더는 JCA와 JCE API로 작성된 기존의 응용프로그램이 네이티브 PKCS#11 토큰에 접근할 수 있도록 해준다. 자세한 정보는 http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html을 참조하길 바란다.

●HSM 보안 토큰
공인인증서의 해킹 사고를 막기 위해 이를 별도의 하드웨어에 저장할 목적으로 HSM(Hardware Security Module) 보안 토큰을 이용한다. 왜냐하면 HSM은 하드웨어 암호 가속기나 스마트카드 같은 암호 토큰과의 네이티브 프로그래밍 인터페이스를 제공하기 때문이다.

따라서 여러 종류의 디바이스에 대한 하드웨어 암호화를 이용하기 위해 HSM을 사용해야 하는데, 이때 PKCS#11 프로바이더를 이용한다. 따라서 자바 5.0 이상에서는 기본적으로 PKCS#11 프로바이더를 사용할 수 있다.

PKCS#11 지원은 디바이스 업체에서 PKCS#11 라이브러리를 제공하면 자바에서는 해당 프로바이더를 이용하여 기능호출이 가능하다. 하지만, PKCS#11 프로바이더 이용 시 SEED 알고리즘을 지원하지 않기 때문에 이에 대한 처리방안을 고려해야 한다.

왜냐하면, SEED 알고리즘은 1999년 한국정보보호센터(현 한국정보보호진흥원)에서 개발한 우리나 라 고유의 알고리즘이기 때문이다. 따라서 SEED 알고리즘을 별도로 Cipher클래스를 상속하여 구현하고 PKCS#11 프로바이더에 등록해주면 문제는 해결될 것이다.

기술적 쟁점 5 – 윈도우 비스타 환경에서의 공인인증서 저장위치 문제
현재 우리나라에서 공인인증서를 저장하는 위치는 PC에서 시스템 폴더 밑에 특정 폴더로 지정되어 있다. 그렇다면 앞서 윈도우 비스타의 IE 7에서 발생한 문제와 동일한 문제가 발생한다. 필자가 가능성 검증을 하지는 못 했지만 이 문제는 자바에서 권한상승 방법을 그대로 이용하면 되지 않을까 싶다.

자바에 기본적으로 내장된 CORBA를 사용해 COM/CORBA Bridge 기술을 적용하는 것도 좋은 방법일 듯하다. 이 방법은 CORBA와 COM의 상호 운용성을 제공한다.

자바가 공인인증서 플랫폼으로 쓰인다면?

이상에서 밝혀졌다시피 자바는 공인인증서 처리 플랫폼으로 사용하는데 장/단점을 자기고 있다. 하지만, 자바가 공인인증서를 처리하는데 충분히 적합하며, 결함이 없다는 데에는 이견이 없을 것이다. 단지 JRE를 엔드유저가 다운 받아야 하고 수행속도도 느릴 수 있다.

파업의 천국 프랑스에서 대중교통 노동자들에 의해 파리에서 3주 동안 지하철과 기차, 시내버스가 단 한 대도 다니지 않았다고 한다. 이때 불편함을 묻는 기자의 질문에 과반수가 넘는 파리 시민이 “불편하지요. 하지만 나는 파업 노동자들을 100% 지지하고 있습니다”라고 답했다고 한다.

자바를 공인인증서 처리 모듈로 사용하기 위해서는 최초 한번 JRE를 깔고 또다시 애플릿을 다운로드해야 하는 부담이 따른다. 하지만 액티브X가 지원되지 않으므로 고생하는 윈도우가 아닌 운영체제, IE가 아닌 웹브라우저 사용자들까지 공인인증서를 사용할 수 있다면 충분히 감내할 수 있는 부담이 아닐까 한다. @

공인인증서 문제 해결을 위한 방법들

특집 2부에서는 공인인증서 문제를 해결하기 위해 자바를 활용하는 방법 위주로 설명하고 있지만, 이 밖에도 여러 가지 방법들이 제안되고 있다. 특히, 오픈웹은 상당히 다양한 방법들에 대해 체계적으로 제시하고 있으며, 이는 다시 단기적인 방법과 장기적인 방법으로 나누어서 설명되고 있다. 오픈웹이 제시하고 있는 단기적 해결 방법과 장기적인 해결 방법은 다음 링크를 통해 확인할 수 있다. ● 단기적 해결 방안 : http://korea.gnu.org/openweb/1/sterm.html ● 장기적 해결 방안 : http://open.unfix.net/%EC%A0%84%EC%9E%90%EC%84%9C%EB%AA%85%EB%B2%95%EA%B3%BC-%EA%B3%B5%EC%9D%B8%EC%9D%B8%EC%A6%9D%EC%84%9Cin-progress/#c9 여기에서는 오픈웹이 제안하고 있는 해결 방법들에 대해 간단히 알아본다. 먼저 단기적인 해결 방안으로 제시하고 있는 기술들은 자바 애플릿과 특집 4부에서 다루고 있는 XPCOM, 플래시(플랙스)와 자바 애플릿의 병행, 플래시, 모질라나 넷스케이프의 플러그인 기능 등이다. 이 중에서 가장 빨리 적용할 수 있는 방법으로는 자바 애플릿과 플래시를 들고 있다. 자바 애플릿에 대해서는 본문에서 설명하고 있지만 다시 간단히 설명하자면, 자바는 높은 수준의 보안을 확보할 수 있을 뿐 아니라 플랫폼에 구애받지 않으면서 인증서를 구현할 수 있다. 또 한 가지 빼놓을 수 없는 장점은 사용자가 컴퓨터에 관리자 권한으로 어떤 프로그램도 설치할 필요가 없기 때문에, 네트워크 관리 기준이 높은 외국에서도 쉽게 사용할 수 있다는 점이다. 물론, 자바 애플릿에도 단점은 있다. 컴퓨터가 자바 애플릿을 다운 받는데 약간의 시간이 걸린다는 점과 가상머신이 마련되는 동안 좀 더 기다려야 한다는 점이다. 다음은 플래시다. 플래시는 자바 애플릿에 비해 내려 받아야 하는 파일의 크기가 작고 플래시 플레이어 자체가 가상머신의 역할을 하기 때문에 자바 애플릿을 쓸 때보다는 시간이 덜 걸린다는 장점이 있다. 또, 높은 안정성을 가지고 있을 뿐 아니라 플래시 플레이어만 설치되어 있다면 매킨토시와 리눅스 등의 운영체제에서도 사용할 수 있다. 관리자 권한이 없는 일반 사용자가 자신의 개인용 파일 시스템에 플래시 플레이어를 설치하는 구조이기 때문에, 보안 위험을 줄이면서도 추가 설치나 업그레이드가 가능하다는 점도 장점이다. 오픈웹에 따르면 이미 국내 보안 업체 중에 플래시와 자바 애플릿을 이용한 공인인증서 처리 솔루션의 개발을 완료한 곳도 있단다. 한 가지를 더 살펴보자. 이번 방법은 브라우저의 확장 플러그인을 사용하는 것이다. 플러그인은 애플릿처럼 어떤 응용프로그램의 이용에 도움이 되는 특정한 부가 기능을 제공하는 보조 프로그램이다. 여기에서 주프로그램과 보조 프로그램 간의 통신과 리소스 호출 방법 등을 제시하는 API는 오픈소스 형태로 공개되어 있다. 대표적인 브라우저로는 파이어폭스가 있으며 플러그인 기반의 인증 기술 또한 국내 기술진에 의해 개발되어 있다고 한다. 다음 표는 오픈웹에서 제안하고 있는 공인인증서 문제의 단기적인 해결 방법들을 비교 정리한 것이다.

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.