전자금융거래의 공인인증/보안프로그램에 관한 제안

오픈웹 김기창입니다. (위로해 주세용~ ^^)

아래에 적은 내용을 KLDPWiki 페이지로 만들었습니다. 직접 수정, 개선해 주시기 바랍니다.

우리의 개발자분들이 겪는 어려움과 한국의 웹환경에 대해서는 모두 나름의 문제 의식이 있으실 것입니다.

그러나, 공무원을 탓하고 보안업계 과점 사업자들의 부도덕을 한탄하며 무기력감에 빠져 있을 것이 아니라, 뚜렷한 기술적 논거로 뒷받침된 합리적 정책 대안을 명시적, 구체적으로 제시, 설명하고, 이것을 관철하도록 노력하는 것이 어느 때 보다도 필요한 시점이라고 생각합니다.

저는 선진적 기술과 국제적 안목을 가진 고급 기술 인력 분들이 제대로 그 견해를 관철 할 수 있고, 그 역량에 맞는 대우를 받는 상황을 만들어 내고 싶습니다. 행정권한을 행사하는 분들이 양심적인 기술전문가들의 조언, 객관적이고 투명하게 검증된 해법을 채택하도록 그 대안을 제시하고 설명할 필요가 있습니다.

인터넷뱅킹/전자금융거래와 관련해서 행정력이나 법제도가 직접적 영향력(파괴력?)을 미치는 분야는 공인인증과 보안프로그램 운용에 관한 부분입니다. 이것과 관련된 기술 설계의 기본 원칙들을 분명히 제시함으로써, 안전하고 합리적이고 확장가능한 전체 서비스 설계가 가능하게 될 것입니다. 우리 나라의 현 사태는, 10년 전 기술로 개발한 PKI client plugin을 줄창 울궈먹으며, 새로운 경쟁 사업자의 시장진입을 막으려는 과점 보안 사업자들의 영업전략에 온 나라의 웹환경이 왜곡되어 온 것이라고 저는 생각합니다.

따라서 "전자금융거래에서의 공인인증/보안프로그램 설계 및 운용 원칙"을 수립 하는 과제를 KLDP에서 공개적으로 수행할 것을 제안드립니다. 공개 프로젝트는 프로그램 소스 개발만을 대상으로 하는 것은 아닐 것입니다. 서비스 설계의 추상적 골격이나, 설계의 기본 가치 등도 공개적 논의와 검토를 거쳐서 개발, 제시되는 것이 바람직하지 않을까 생각합니다.

금융권 IT 관계자, 보안업체의 (양식있는) 기술전문가, 행정부의 기술 관계자 등이 자기 신분을 밝힐 필요 없이 닉네임으로 참여하고, 많은 분들의 공개적 논의를 거쳐 대안이 수립되면, 그 결과를 금융감독원과 행정안전부에 공식적으로 제안할 예정입니다.

1. 근본 가치

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

2. 공인인증

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

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

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

2-1. 서버측 인증 솔루션

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

2-2. 인증 클라이언트(PKI client plugin)

2-2-1. 장기적으로는 거래내역 서명 기능(form-signing capability)이 웹브라우저에 탑재되는 상황도 상정해 볼 수는 있으나, 현재로서는 거래내역 서명 기능은 웹브라우저 플러그인으로 구현될 수 밖에 없다.
2-2-2. PKI client는 순수히 전자서명 기능만을 수행하고, 인증서 관리 기능은 웹브라우저에 기본 탑재된 모듈을 사용하는 것이 합리적이다. 보안 접속은 https로 한다.
2-2-3. 따라서 현재의 공인인증서 저장 위치, 저장 양식 등은 표준적으로 수정될 필요가 있다.(pfx, p12 양식으로 저장하거나, 웹브라우저의 인증서 저장위치에 저장)
2-2-4. 서버측 인증 솔루션과 인증 클라이언트 간의 종속을 제거하는 방안은 다음과 같다:

2-2-4-1. 서버가 PKI client를 호출/구동하는 방법, PKI client가 처리하는 각 필드 값의 명칭, 에러 코드, PKI client가 수행하는 각 기능을 호출하는데 사용되는 parameters 명칭 등을 표준화하여, 어떤 PKI client 가 이용자의 컴퓨터에 설치되어 있더라도, 서버가 이를 호출, 구동, 사용할 수 있도록 하는 방법: 이 경우 보안업체 들은 여전히 제각각 PKI client 를 만들어 공급하기는 하겠으나, 그 클라이언트가 서버와 교신하는데 사용되는 인터페이스가 위와 같이 표준화 되므로, 서버는 특정 업체 제공 PKI client 에 종속되지 않고 자유로이 아무 client 건 호출/구동하여 사용할 수 있게 된다. 이 경우, 서버측 웹페이지 작성 방법, 보안업체들이 자기가 개발, 제공하는 PKI client 에 대한 대가를 수령하는 방법이 지금과는 달라져야 한다.

2-2-4-2. PKI client를 서버가 호출, 구동, 사용하는 방법(interface)은 위와 같이 통일하되, 5개 공인인증기관이 이 규격을 준수하는 PKI client를 각각 제공하거나, 5개 공인인증기관이 공동 제작한 하나의 PKI client를 사용하는 방법: 이 경우, 보안 업체는 더 이상 PKI client를 제작, 공급/판매 하지는 않게 된다. 그 대신, 모든 보안 업체들은 서버측 인증 솔루션 영업에 집중하여 사업을 수행하게 되고, 오히려 이럴 경우 공평한 경쟁환경이 확보될 수 있다(꼬리가 개를 흔드는 형국은 중단된다).

2-2-4-3. 공인인증기관이 제공하는 PKI client는 감독관청의 심사를 받은 것이므로, 이러한 가입자 설비로 생성시킨 전자서명은 "공인전자서명"으로서의 법률상 효과를 가질 수 있게 된다. 거래 당사자들로부터 중립적인 인증기관이 아니라, 거래의 일방 당사자가 임의로 자체 제공하는 私製소프트웨어로 생성시킨 전자서명은 거래 일방이 챙겨두는 무의미한 私的데이터에 불과하고, "공인전자서명"이 아니다.


2-2-5. PKI client 와 서버측 인증 솔루션 간의 종속관계가 이처럼 제거되고 나면,서버측 인증 루틴을 모듈러라이즈 하는 작업은 손쉽게 달성되고, 서버측의 서비스 설계 구조가 전반적으로 합리화되고, 유연성과 확장 가능성이 확보된다.

3. 키보드 보안프로그램

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

4. 프로그램 배포(deployment) 방식

4-1. 키보드 보안 프로그램:

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

4-2. PKI client:

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

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

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

보안 업체, 금융권에서 이 문제에 관심을 가진 분들이 가급적 많이 참여하셔서, 합리적인 정책 대안이 마련되면 금융감독원과 행정안전부에 제시하면 채택되지 않겠습니까? 몇몇 기존 업체들의 반발이 있겠지만, 그들 업체들의 영업/과점 이익 만을 위해서 온 나라, 온 국민들이 불편을 겪는 현재의 상황은 정의롭지 못하다고 생각합니다.

어떻게 생각 하시는지요?