• 서비스의 안전성
• 설계 구조의 투명성, 객관적 검증 가능성
• 업체 간의 공평하고 자유로운 경쟁 보장
• 솔루션의 유연성, 확장 가능성 극대화
  
  

공인인증서 사용을 법령으로 강제하는 나라는 한국 밖에 없다. 이 규정(전자금융감독규정 제7조)은 수정되어야 한다. 국회는 전자거래를 더욱 활성화할 목적으로 전자서명제도를 도입하였는데(전자서명법 제1조), 법에도 없고, 시행령에도 없는, 금감원이 고시한 감독규정에 삽입된 이 조항때문에 오히려 전자거래가 위축된다. 이 규정은 금융기관들이 정상적인 전자거래에 대하여까지도 (전자서명이 없다는 이유로) 거래 효력을 일률적으로 부인하거나, 불리하게 대우하는 핑계로만 사용된다.

전자서명은 거래 주체가 자율적으로 채용여부를 판단하도록 해야 한다. 현재 금융감독원 관계자는 "전자서명"이 마치 교신의 암호화를 제공하는 듯 오해하고 계시지만, 전자서명(electronic signature)은 보안접속(secure connection)과는 기술적으로 무관하다.

(공인)인증은 클라이언트 소프트웨어와 서버측 인증 솔루션을 분명히 구분하여 해법을 모색해야 한다.

1. 서버측 인증 루틴은 모듈러라이즈(modularize) 하여 재사용 가능한 컴포넌트로 구축한다.
2. 서버측 인증 솔루션과 인증 클라이언트 소프트웨어 간의 인터페이스를 표준화함으로써 양자 간의 종속관계를 제거한다.
3. 서버측 인증 솔루션 시장은 완전히 자유로운 경쟁이 보장되어야 한다. 누구라도, PKI client plugin 을 새삼스럽게 중복 개발하지 않더라도, 서버측 인증 솔루션 시장에 참여할 수 있어야 한다.
4. 개발자의 독창성과 업체의 기술력이 진정으로 발휘될 수 있는 분야는 서버측 인증 솔루션 분야이다. 서비스 설계의 확장가능성에 착안하여, 인증 솔루션을 활용하여 다양하고 참신한 거래 서비스에 인증서비스를 연계하여 설계하고 구현하는 창의적 업체들이 활발히 등장할 수 있도록 보장할 경우, 서버측 인증 솔루션 시장은 막대한 성장잠재력을 가질 수 있고, 우리의 보안산업은 진정한 발전과 성장이 가능하게 된다.
5. 인증 클라이언트와 서버측 인증솔루션이 결합(lock-in)된 현 상황에서는 클라이언트 플러그인을 쥐고 있는 일부 업체들(이니텍, 소프트포럼, 펜타시큐리티, 시큐어 소프트, 비시큐어, 드림 시큐리티 등)이 서버측 인증 솔루션 시장까지 좌지우지하며, 이들 업체의 기술 수준에서 국내 보안 산업의 기술 수준이 규정되어버려, 정체와 답보 상태를 면하지 못하고 있다. 개가 꼬리를 흔드는 것이 아니라, 꼬리가 개를 흔드는 형국이다.
   
   

1. 장기적으로는 거래내역 서명 기능(form-signing capability)이 웹브라우저에 탑재되는 상황도 상정해 볼 수는 있으나, 현재로서는 거래내역 서명 기능은 웹브라우저 플러그인으로 구현될 수 밖에 없다.
2. PKI client는 순수히 전자서명 기능만을 수행하고, 인증서 관리 기능은 웹브라우저에 기본 탑재된 모듈을 사용하는 것이 합리적이다. 보안 접속은 https로 한다.
3. 따라서 현재의 공인인증서 저장 위치, 저장 양식 등은 표준적으로 수정될 필요가 있다.(pfx, p12 양식으로 저장하거나, 웹브라우저의 인증서 저장위치에 저장)
4. 서버측 인증 솔루션과 인증 클라이언트 간의 종속을 제거하는 방안은 다음과 같다:
   
   
   • 서버가 PKI client를 호출/구동하는 방법, PKI client가 처리하는 각 필드 값의 명칭, 에러 코드, PKI client가 수행하는 각 기능을 호출하는데 사용되는 parameters 명칭 등을 표준화하여, 어떤 PKI client 가 이용자의 컴퓨터에 설치되어 있더라도, 서버가 이를 호출, 구동, 사용할 수 있도록 하는 방법 (예를 들어, 이 문서처럼 parameters 명칭과 기능을 설명하는 documentation 에 업체들이 합의하여 이를 공표, 준수): 이 경우 보안업체 들은 여전히 제각각 PKI client 를 만들어 공급하기는 하겠으나, 그 클라이언트가 서버와 교신하는데 사용되는 인터페이스가 위와 같이 표준화 되므로, 서버는 특정 업체 제공 PKI client 에 종속되지 않고 자유로이 아무 client 건 호출/구동하여 사용할 수 있게 된다. 이 경우, 서버측 웹페이지 작성 방법, 보안업체들이 자기가 개발, 제공하는 PKI client 에 대한 대가를 수령하는 방법이 지금과는 달라져야 한다.
     
     
   • PKI client를 서버가 호출, 구동, 사용하는 방법(interface)은 위와 같이 통일하되, 5개 공인인증기관이 이 규격을 준수하는 PKI client를 각각 제공하거나, 5개 공인인증기관이 공동 제작한 하나의 PKI client를 사용하는 방법: 이 경우, 보안 업체는 더 이상 PKI client를 제작, 공급/판매 하지는 않게 된다. 그 대신, 모든 보안 업체들은 서버측 인증 솔루션 영업에 집중하여 사업을 수행하게 되고, 오히려 이럴 경우 공평한 경쟁환경이 확보될 수 있다(꼬리가 개를 흔드는 형국은 중단된다).
     
     
   • 더이상 PKI client 로 장사하는 것이 기술적/사업적으로 무의미하다는 인식이 널리 수용될 경우, 5개 공인인증기관이 공동으로 공개소스 형태의 PKI client 를 개발, 배포하는 것이 가장 바람직하다. 안전성과 범용성에 대한 가장 만족스러운 수준의 검증이 가능하기 때문이다.
     
     
   • 공인인증기관이 제공하는 PKI client는 감독관청의 심사와 검증을 받은 것이므로, 이러한 가입자 설비로 생성시킨 전자서명은 "공인전자서명"으로서의 법률상 효과를 가질 수 있게 된다.
     
     
   • 거래 당사자들로부터 중립적인 인증기관이 아니라, 거래의 일방 당사자가 임의로 자체 제공하는 私製소프트웨어로 생성시킨 전자서명은 거래 일방이 챙겨두는 무의미한 私的데이터에 불과할 뿐, "공인전자서명"이 아니다. 서명자, 감독관청, 법원 등은 그 私的데이터가 생성된 기술적 메커니즘에 대한 공신력있는 어떠한 사전, 사후 검증도 불가능하므로, 이러한 데이터는 분쟁발생시 서명자가 그 효력을 부인할 경우, 아무런 법적 효력도 인정받지 못한다(부인방지 효력이 없다).
     
     
5. PKI client 와 서버측 인증 솔루션 간의 종속관계가 이처럼 제거되고 나면,서버측 인증 루틴을 모듈러라이즈 하는 작업은 손쉽게 달성되고, 서버측의 서비스 설계 구조가 전반적으로 합리화되고, 유연성과 확장 가능성이 확보된다.
   
   

1. 키보드 보안 프로그램은 "현재의 국내 사용자들의 이용 습관때문에 형성된 환경(모든 이용자들에게 끊임 없이 '예'하라고 안내해 온 나머지, 많은 이용자들이 실제로 '예'를 거듭 눌러온 기형적인 환경) 하에서는" 어느 정도 유용성이 있다. 그러나, 이 프로그램을 사용하려면 관리자 권한으로 컴퓨터를 운용하도록 강제되므로, 이 프로그램의 사용을 일률적으로 강요할 경우 부작용도 크다.
2. 일회용 비밀번호(OTP)를 사용하더라도, 인증서 개인키 암호입력 부분은 현재 OTP 적용이 현실적으로 어렵고, 이 부분에 대한 "높은 수준"의 키보드 보안 효과를 위해서는 PKI client 와 키보드 보안 프로그램 간의 인터페이스가 필요하다.
3. 전자서명과 마찬가지로, 키보드 보안 프로그램도 불가피하게 웹브라우저 플러그인 방식으로 구현해야 하는 실정이다.
4. 키보드 보안 프로그램 중에는 PKI client와 무관하게 단순히 키 값만을 인터셉트해서 처리하는 것들도 있고, PKI client module과 직접 교신하는 것들도 있다(後者를 편의상 "end2end 키보드 보안"이라 부르겠습니다).
5. 서버측 인증 솔루션과 PKI client 간의 종속관계가 제거되고, PKI client의 기술 사양이 투명하게 공개되면, end2end 키보드 보안 프로그램을 설계하는 업체들에게 도움이 되고, 자유로운 경쟁환경이 가능하게 된다. PKI client 와 e2e 키보드 보안 프로그램 간의 종속 관계도 제거되기 때문이다.
6. 그러나 현재는 PKI client 와 서버측 인증 솔루션이 lock-in 되어있을 뿐 아니라, 제 각각의 PKI client 들의 기술 specs 이 전혀 공개되어 있지 않으므로, e2e 키보드 보안 프로그램은 PKI client 를 이미 가지고 있는 업체들만 개발, 구현할 수 있는 실정이다. PKI client를 미끼로 하여 e2e 키보드 보안 프로그램 시장까지 통제, 장악하는 구조이다. (bundling 의 대표적 사례이다)
7. 또한, 특정 금융기관이 특정 키보드 보안 프로그램을 그 고객에게 제공하고, 그 사용을 강제하는 현 상황은 경쟁법에 위반될 소지가 있다. 금융거래 서비스라는 주상품을 공급하는 조건으로 키보드 보안 프로그램이라는 부상품을 "끼워파는" 상황이기 때문이다(부상품이 무료라 하더라도 끼워팔기로 될 수 있다; 해당 부상품 시장의 자유로운 경쟁을 저해하기 때문이다).
8. 따라서, 금융기관과 키보드 보안 프로그램 간의 결합(종속) 관계도 제거되어야 한다.
   
   

1. 키보드 보안프로그램은 금융감독원이 그 사용을 지도하는 것이므로, 금융감독원이 그 프로그램에 대한 심사를 한다(지금도 형식은 그렇습니다). 심사를 필한 키보드 보안제품들의 "설치파일 내려받기 통합 페이지"는 키보드 보안 프로그램 공급자들이 공동으로 단일한 페이지를 운영한다. 이 페이지 자체는 https 로 접속하되, 그 페이지에 제시되는 각 제품의 내려받기 링크 주소는 http 로 운영한다. 이 페이지에는 각 제품의 공급자 명칭, 기능 등을 간략히 안내하고, 소비자가 그곳에 안내된 여러 제품 중 자유롭게 선택하여 내려받을 수 있도록 한다.
2. 금융기관 등은 키보드 보안프로그램을 호출해야 하는 페이지에서, 위 여러 제품 중, 어느 하나의 플러그인이라도 이용자의 컴퓨터에 설치되어 있으면, 그것을 호출하도록 웹페이지 소스를 적는다(if, elseif, elseif, ...., else 등의 방식...)
3. 키보드 보안프로그램이 전혀 설치되어 있지 않은 이용자에게는 i) 키보드 보안프로그램의 유용성을 설명하고, ii) 통합 내려받기 페이지로 갈 수 있는 링크를 제시하고, iii) 키보드 보안프로그램을 설치 하지 않기로 선택하는 이용자의 경우, 이점을 확인할 수 있도록 체크박스를 제시한다.
4. 키보드 보안 프로그램 사용을 안하기로 체크한 이용자에게는 다음부터는 위의 안내 페이지가 나타나지 않도록 한다(쿠키 이용)
5. 내려받기 통합 페이지로 유입하는 트래픽의 referrer 가 어느 금융기관이었는지에 대한 통계를 계산하면, 어느 금융기관의 고객들이 내려받기 페이지로 왔는지 그 비율을 계산할 수 있다. 그리고, 각 보안프로그램의 다운로드 회수를 계산하면, 최종 소비자가 각 프로그램을 선택한 비율도 계산할 수 있다. 이 두 비율에 기초하여, 일정한 합리성을 가진 비용 지급/대가수령 구조를 고안할 수 있다. 즉, 키보드 보안프로그램 공급자들에게 지급될 액수의 총액을 적절한 수준에서 책정한 다음(X), 각 금융기관들은 내려 받기 페이지로 들어온 트래픽 중, 자기 페이지에서 refer 된 비율에 상응하는 분담금을 지급하여 그 합계액이 X가 되도록 하고, 보안프로그램 공급자들은 자기 프로그램이 다운로드 된 비율에 따라 X 를 나누어 가진다.
6. 물론, 이 계산방법은 완벽하게 정확하지는 않지만, 관련 당사자들에게는 어느 정도 합리적 방법으로서 수용될 여지가 있다. 다른 경로로 "통합 내려받기 안내" 페이지로 와서 다운로드 받는 사람들이 있다 하더라도, 금융기관이 이것을 싫어할 리는 없고(자기 부담부분이 줄어들면 줄어들지 늘어나지는 않으므로), 프로그램 제공자 역시 어차피 많은 사람이 자기 프로그램을 다운로드 받으면 자기 수령액이 늘어나므로 싫어할 이유는 없을 것이다. 키보드 보안 프로그램 공급자들에게 지급될 총액(X)을 적정하게 책정하고 나면, 나머지는 분담금이나, 수령금의 액수가 아니라, "비율" 문제만이 남기 때문이다. 금융기관 웹사이트가, 자기 부담 부분을 줄이기 위해서, 고객들에게 "다른 페이지로 갔다가, 통합내려받기 페이지로 접속해 주세요"라고 안내할 수는 없을 것이다. 완벽하게 정확한 계산 방법은 아니겠지만, 상당한 수준의 합리성 있는 비용 분담 체계로 인정받을 수는 있을 것이다. 물론, 프로그램 공급업체들이 공동으로 보다 정확한 대가 수령 구조를 고안할 수도 있을 것이다.
7. 키보드 보안프로그램 설치 과정에서는 해당 프로그램의 코드 서명자의 인증서를 신뢰할지 여부를 묻고, 이용자가 신뢰하기로 선택하면 신뢰된 게시자로 등록할 수 있도록 한다. 이렇게 하면, 실제로 금융기관 웹페이지에 이용자가 접속하여 이용하는 중에는, 보안경고창이 뜨지 않고 (자기가 이미 설치한) 키보드 보안 플러그인이 호출, 구동될 수 있게 된다.
   

1. 역시 위와 유사한 방법으로 설치프로그램을 배포한다.
2. 다양한 보안 업체가, 동일한 호출, 구동, 이용방법을 준수하는 PKI client 를 각각 공급할 경우, 그 대가 지급 관계는 위에 설명한 방법과 유사하게 운영될 수 있다. 웹서버들의 해당 페이지 소스 작성도 위에 설명한 것과 유사하게 운영(if, elseif, elseif.... else).
3. 공인인증기관이, 동일한 규격을 준수하는 PKI client 를 각각 공급하거나, 공동제작한 하나의 PKI client 를 제공할 경우, 각 공인인증기관의 페이지에서 해당 프로그램 설치파일을 내려받을 수 있도록 한다.
4. PKI client 설치 과정에서도 코드 서명자의 인증서를 신뢰된 게시자로 설치할지 여부를 이용자에게 묻고 설치할 수 있도록 한다.
   
   

PKI client 건, 키보드 보안 프로그램 이건 간에 개별 서비스 제공자의 웹페이지 소스에는 codebase (또는 xpi 내려받기 주소) 를 지정하지 않는다. 플러그인 프로그램을 이렇게 배포하면, 이용자들에게 "보안경고창이 나타나면 반드시 '예'를 누르라"는 괴상한 안내를 하지 않아도 될 것이다.

그 외의 이른바 "보안프로그램" (방화벽, 안티바이러스, 안티피싱 등)은 순전히 자율적 서비스 차원에서 각 금융기관이 제공 여부를 결정함이 옳으며, 아예 논외로 한다.

• 현재 기술 규격6.1은 가입자 인증서를, 윈도우 OS의 경우에 시스템 폴더(C:\Program Files\) 내에 NPKI 폴더를 생성하고 그 하위에 저장하도록 규정하고 있다. 매킨토시와 유닉스 계열 OS 의 경우에는 이용자의 폴더에 저장하도록 규정하고 있다.
• 이러한 기술 규격은 윈도우 OS에 이용자/관리자 계정의 권한 구분이 불분명했던 시절에나 통용될 선택이다.
• 가입자 인증서는 일반이용자 권한으로 파일쓰기가 가능한 위치에 저장하는 것이 옳다.
• 컴퓨터 운용지식이 없는 이용자가 "실수로" 인증서를 삭제할 가능성이 있다는 이유로 인증서를 시스템 폴더에 저장하는 것은 논리적으로도 모순이다. 이럴 경우, 관리자 권한으로 컴퓨터를 사용하도록 강요하게 되는데, 그럴 경우 운용지식이 없는 이용자는 어디에 있는 파일이건 간에 실수로 삭제할 위험이 더욱커진다.
  
  

• 현재는 인증서와 개인키를 별도의 파일로 저장하고 있다. 이런 형식으로 저장된 인증서/개인키는 범용적 이용이 불가능하고 호환성이 없다. 기술적으로 납득이 가지 않는 선택이다.
• 웹브라우저의 인증서 저장 위치에 저장하거나, pkcs#12 형식으로 저장하는 것이 옳다.
• 저장형식을 이렇게 한다고 해서, 이용자의 불편이 커지는 것도 아니다. 인증서 선택 창에서는 웹브라우저에 저장된 인증서의 목록을 기본으로 제시하고, 파일 선택을 가능하게 하는 창에는 .p12 또는 .pfx 확장자 필터를 채용하면, 일반이용자도 아무 불편없이 자신의 인증서를 선택할 수 있다.
• 현재, 전자금융감독규정은 "공인인증서를 사용할 것"이라고만 규정되어 있으므로, 공인인증서가 호환적, 표준적 형식으로 이렇게 저장될 경우, 서비스 제공자는 웹브라우저에 기본 탑재된 client certificate authentication 만을 채용하고 서비스를 제공해도 기존의 규정이 요구하는 사항을 모두 충족하고 유연하고 다양한 방식으로 서비스를 적법하게 제공할 수 있다.
• 금융감독원도, 현재의 규정을 일부러 축소 해석하여 "거래 내역에 대한 전자서명"을 반드시 강요할 이유는 없다. 만일 금감원이 규정에도 없는 "거래 내역에 대한 전자서명"을 고집하는 정책을 취한다면, 기존의 PKI plugin사업자들의 이해관계만을 위하여 우리나라 전자거래 서비스 전체를 위축, 제약시키고 발목을 잡는다는 비난에서 자유로울 수 없을 것이다.