MS IE 전용, 플래시 떡칠 페이지가 난무하는 한국의 인터넷 환경을 개선하기 위하여 오픈웹을 시작한지 4년이 되었습니다. 많은 분들이 열정적으로 지원해 주셨습니다.

가장 먼저 당시 전자정부 사이트가 화답했습니다. 공공기관 웹페이지의 개편 일정을 마련하고, 앞으로는 다양한 OS/웹브라우저에서 공공기관 웹페이지 이용에 불편이나 차별이 없도록 하겠다는 약속을 당시 전자정부 본부장님께서 직접 해주셨습니다. 그 약속은 대부분 지켜졌습니다. 이제, 적어도 3종 이상의 웹브라우저에서 이용에 불편이 없어야 한다는 것은 확고한 요건이 되었습니다.

그러나 인터넷 뱅킹/쇼핑 등 전자금융거래 분야에서는 “보안” 때문에 어쩔 수 없다는 주장이 완강하게 제기되었습니다. 다양한 웹브라우저/OS에서 전자금융거래를 제공하는 것은 보안 때문에 “불가능하다” 또는 “천문학적인 비용이 든다”는 것이었습니다. 그동안 끝없이 반복되었던 관련 업계의 이런 주장들이 거짓말이었다는 사실은 이제 우리은행의 오픈뱅킹 서비스가 분명히 보여주고 있습니다. 구체적으로,

1. 페이지 레이아웃: “한국사람들은 ‘화려한’ 페이지를 선호하므로 무조건 플래시를 쳐발라야 한다”는 천박한 주장은 사실이 아닙니다. 우리 오픈뱅킹 페이지는 플래시를 사용하지 않습니다. 많은 사람들이 그 깔끔함을 반기고 있습니다. 훨씬 이용하기 편할 뿐 아니라, “보기 싫다”는 평은 아무도 하지 않습니다.

2. 메뉴 구성: “드롭다운 메뉴, 인터엑티브 메뉴를 위해서는 플래시를 사용해야 한다”는 주장도 거짓입니다. 우리 오픈뱅킹은 플래시를 사용하지 않고 드롭다운 메뉴를 구현하고 있습니다. 다른 은행들의 메뉴는 마우스를 갖다대면 슬그머니 하위메뉴가 나타나고, 마우스 위치가 조금이라도 벗어나면 사라져 버려서, 마치 ‘쥐잡기’ 하듯 마우스를 ‘정조준’하도록 유저를 고생시키는 뻘짓을 거듭하고 있습니다. 우리은행은 그렇지 않습니다.

3. 교신 암호화: “웹브라우저를 사용한 SSL 암호화는 페이지를 통째로 암호화하므로 서버에 부담이 크고 속도가 느려진다. 플러그인으로 암호화를 하면 필요한 부분만 암호화하므로 더 빠르다”는 주장도 사실이 아닙니다. 페이지를 깔끔하게, 경량으로 구성하고 웹브라우저의 SSL 암호화 기능을 사용하는 우리 오픈뱅킹은 기존의 국내은행들보다 더 빠른 쾌속스피드를 자랑합니다.

4. 보안프로그램: “보안3종세트는 반드시 설치해야 한다, 금감원 규정때문에 어쩔 수 없다”는 것도 거짓말입니다. 유저가 원하면 설치하지 않아도 되도록 규정되어 있습니다. 국민은행도 이미 여러해 동안 그렇게 해왔고, 우리은행도 개인방화벽 프로그램 설치를 강요하지는 않습니다. 금감원도 보안3종세트에 대하여 유저가 원하면 “미설치할 수 있다는 의미”라고 공식적으로 민원회신 하였습니다. 안랩, 잉카인터넷 등의 방화벽, 안티바이러스, 키보드보안프로그램을 “설치하지 않는 즐거움”을 만끽하실 수 있습니다. 그런 기쁨과 자유를 박탈하고 유저를 노예 취급하는 은행과는 거래를 끊으십시오.

5. 개편 비용: “다양한 유저 환경을 지원하려면 천문학적인 돈이 든다”는 주장이 지겹도록 반복되었습니다. 흠… 그렇다면 우리은행은 천문학적인 투자를 할 여력이 있었나 봅니다 ^^

사실 우리은행 오픈뱅킹이 가능했던 이유는 기존 보안업체들에게 의존하지 않고, 우리은행의 자체 기술인력(우리FIS)이 독자적으로 극비리에 개발을 완료하였기 때문입니다. IE에서 액티브액스를 사용해야만 ‘안전’한 거래가 가능하다는 주장은 한마디로 허무맹랑하지만, 국내의 보안업체들이 “천문학적인 돈이 든다”는 거짓 주장을 거듭한 이유는 솔직히 “어떻게 하면 되는지 모른다”는 말을 하기가 부끄러워서 그랬던 것이 아닐까 하는 생각도 …

오픈웹의 취지를 이해하고, 적극 수용해 주신 우리은행에 경의를 표합니다.

iphoneOS 는 OS 자체가 디지털 인증서 관리나 키 관리, 암복호화, 디지털 서명 등의 기능을 제공하 고 있기에 이를 간단히 소개할까 합니다.  아이폰에서 은행의 공인 인증서를 사용하고자 하는 개발자와 기술 기준에 관심있는 분들께 부족하나마 참고가 되기를 바랍니다.  기본적인 아이폰에서의 디지털 인증서 사용에 대한 일반적인 소개는 이 영문 PDF 문서를 참고하십시오.

아이폰 OS가 제공하는 인증서 관련 서비스는 크게 3가지로 분류 됩니다.

1. 인증서, 키, 신뢰 서비스 (기술문서 링 크)

• 인증서나 키를 관리하거나 PKCS#12등으로 키꾸러미를 import/export 하는 서비스 함수들
• 공개키-개인키 페어를 만들수 있는 함수
• 데이터를 암호화 복호화 하는 함수
• 데이터를 개인키로 서명하거나 데이터의 서명을 인증서로 검증하는 함수
• X509나 SSL등의 정책객체를 획득하는 함수
• 인증서와 정책 객체로 신뢰 관리 객체를 생성하거나 이를 평가하는 함수
• 이를 위해 인증서 신뢰 체인과 유효 기간 등을 관리하는 함수

2.  키 체인 서비스 (기술문서 링 크)

• 키 링에서 속성이 일치하는 키 찾아 얻어내는 함수
• 키 링에 새로운 키를 삽입하거나 수정하거나 삭제하는 함수.

3.  난수 발생 기능  ( 기술문서 링크)

• 간단 합니다. 안전한 난수를 발생시키는 함수

참으로 기본적인 기능만 있기는 합니다만 꼭 필요한 건 거의 다 있군요.  공인인증서를 사용하여 인터넷 뱅킹을 하려면 아이폰 OS에서 제공하는 이 서비스들을 이용해 구현하는 것이 KISA가  기술기준에서 아이폰 용 앱에서 인증서 획득방식으로  제시한 방식 ( 기술 기준 문서 6.2장) 보다 더 나은게 아닐까 하고 생각합니다.

KISA가  제시한 기술 기준은 단지 외부 (PC)에서 아이폰 쪽으로 PKCS #12 인증서/키 꾸러미를 수입하는 데만 사용하고,  각 개별 어플이 직접 p12 꾸러미를 수입하거나  다루지 않았으면 합니다.   p12  키꾸러미는 아이폰 사용자의 configuration profile 데이터의 일부로 등록, 저장되니까  이메일이나  웹 다운로드, SCEP등으로 입수한 p12 파일을 아이폰 사용자의 개인 프로파일에 등록할  수 있습니다.

그러니 공인인증서나 개인키를 사용하는 개별 어플 들이  p12 파일을 직접 키링으로 import 하거나 KISA가 제시하는 공용 어플로부터 p12 스트링을 획득하는 방식을 사용하지를  않았으면 좋겠다고 생각합니다. 그리고 아이폰으로 뱅킹을 하는 뱅킹 어플들도 자체적인  key store/key ring 이나 암호화 라이브러리를  사용하지 말고 이 iphone OS가 제공하는 “공개적이고 표준적이고 다른 국제적 어플들도 공통으로 사용하는” 서비스를 통해 뱅킹 어플을 구현 하기를 제안합니다. 그러면  은행에서 발급받은 개인의 공인 인증서로 SSL 클라이언트 인증으로 SSL 자동  로그인 등이 가능하게  되는 등 아이폰의 싸파리 웹 브라우저에서도 공인인증서를 사용할수 있게 될 겁니다.

다만 이런 개인 정보 프로파일에 p12 파일을 등록하는 과정을 어려워 할, 일부 컴맹 사용자들을 위해 공용 뱅킹 아이폰 앱 정도는 PC로 부터 전송된  PKCS#12 꾸러미 파일 로부터 프로파일의 공용 키체인에 자동으로 삽입해주는 쉬운 Wizard 도우미 기능 정도는 필요할지도 모르겠군요.

그러면 인증서와 개인 키의 입수와 관리 기능은 공용 뱅킹 앱만 구현하면 되고 다른 공인 인증서를 이용하는 어플 (예를 들어 싸파리 웹브라우저, 전자 이메일 서명 어플, 파일 암복호화 어플  등)은 인증서 키 수입이나 관리 기능을 구현할 필요 없이 위의 인증서 나열/선택, 암복호화와 서명, 서명 확인 등의 함수만 이용하여 원하는 기능을 구현해도 충분하지 싶습니다.

전자금융거래법 제21조 제3항은 다음과 같습니다.

③금융위원회는 전자금융거래의 안전성과 신뢰성을 확보하기 위하여 「전자서명법」 제2조제8호의 공인인증서의 사용 등 인증방법에 대하여 필요한 기준을 정할 수 있다.

이 조항에 근거하여, 금융위원회는 “전자금융 감독규정” 제7조에서 “모든 전자금융거래에 있어 「전자서명법」에 의한 공인인증서를 사용하여야 한다…”고 정해두고, 은행, 카드사 등 전자금융 사업자들이 오로지 공인인증서만을 사용하도록 강제하고 있습니다.

그러나, 인증(authentication)은 다양한 수단과 기술로 이루어지는 것입니다. 미국 연방 금융감독 위원회가 2005년에 작성한 “인터넷 뱅킹 환경에서의 인증(Authentication in an Internet Banking Environment)“이라는 문서에도 “특정 기술을 지지하지 않는다”는 점이 명시되어 있습니다(제1면). (This guidance applies to both retail and commercial customers and does not endorse any particular technology.) 이 문서는 미국의 금융감독 위원회가 미국의 은행들의 인터넷 뱅킹 보안에 대한 가이드라인으로 작성한 것으로서, 금융기관은 위험의 종류와 수준을 자체적으로 분석하고 그에 상응하는 대응책을 스스로 판단하여 적절히 도입하도록 권고하고 있습니다. 거래의 성격과 위험 수준에 따라서는 Single factor 인증으로 충분한 경우도 있고, 이것이 적절하지 않은 성격의 거래에는 multi factor 인증이나 계층적 보안책 (layered security) 을 사용하는 것이 적절하다는 내용이며, 은행은 특히 다음 사항을 유의하도록 규정하고 있습니다:

• 고객 계몽 노력의 중요성 (customer awareness efforts)
• 기술 변화 동향을 적절히 반영
• 위험 및 대비책에 대한 자기 분석 , 평가 , 개선

물론, 국내에서는 미국의 전자금융거래가 ‘후진적’이라고 폄하하며, 미국에서는 실시간 타행이체가 안된다는 주장이 제기되지만, 사실은 그렇지 않습니다. 미국의 타행이체는 fedwire 또는 CHIPS 라는 은행간 결제 메카니즘을 이용하며, 이 둘은 모두 실시간 은행간 결제 시스템(real-time gross settlement system)입니다. 기업 고객은 실시간 이체서비스가 제공되며, 개인 고객의 경우 실시간 이체를 못하는 것이 아니라, 안하는 것일 뿐입니다. (물론, 신용카드 거래는 전세계적으로 거래 소요시간에 차이가 없습니다).

또한 일본과 유럽 은행들의 타행이체 서비스 소요시간은 우리와 별 차이가 없습니다.

은행감독에 관한 바젤위원회(Basel Committee on Banking Supervision)는 은행감독에 관한 글로벌 스탠더드를 정하는 곳이라고 할 수 있습니다. 한국도 2009.3.15. 바젤 위원회 회원국이 되었습니다. 바젤 위원회가 채택한 “전자금융 위험관리 원칙“을 보면,

은행은 PIN, 암호, 스마트카드, 생체정보, 디지털인증서 등을 포함한 다양한 인증 기법을 사용할 수 있다.
…
어떤 인증 기법을 사용할 것인지는 전자금융 시스템 전반 또는 각 구성 부분이 제기하는 위험에 대한 경영진의 평가에 기초하여 은행이 결정하여야 한다.

고 되어 있습니다.

따라서, 오로지 인증서 기술만의 사용을 강제하는 현행 전자금융 감독규정은 국제적으로 승인되고 있는 은행감독의 기본 원칙에 어긋나는 것입니다. 우리 국회 입법조사처도 액티브액스 기술 관련 조사 보고서에서 특정기술 사용을 강제해서는 안된다는 원칙을 밝히고 있습니다(제5면).

이러한 국내외의 일치된 견해에 근거하여 조승수 의원은 전자금융거래법 제21조를 개정하여, 다음 조항을 신설할 예정입니다:

금융 위원회는 특정 기술의 사용을 강제하여서는 아니된다.

우리 금융위원회가 준수해야 할 바젤 은행감독 위원회의 전자금융 위험관리 원칙에서도, “본 보고서는 구체적 위험에 대비한 특정 기술 해법을 강제하거나 전자금융 거래의 기술 표준을 정하려는 것이 아니다. 기술적 사안은 금융기관들과 각종 표준화 기구들이 기술 진보에 상응하여 지속적으로 대처할 사안이다… 이런 이유로, 본 위원회는 전자금융 위험관리를 ‘한가지 획일적 해법으로’ 대처하는 것이 적절하다고 믿지는 않는다.”라고 되어 있습니다.

인증서 기술이 만병통치약도 아닌데, 인증서 기술만의 사용을 규정으로 강제하는 것은 상식을 벗어난 것입니다. 인증서를 사용하고 싶은 은행은 사용하고, 다른 기술로 고객과 서버를 인증하고 안전하게 거래하기를 원하는 은행이 있으면, 이런 은행의 사업을 금감원이 규정을 동원하여 가로막아서는 안될 것입니다.

특정 기술의 사용을 정부가 강제하는 순간, 이해관계와 기득권을 누리는 일부업체들이 생겨나고, 이들 업체들은 더 앞선 기술이 국내 시장에 진입하지 못하도록 규정과 행정력을 동원하여 가로막는 등, 국내의 관련 산업이 정체와 낙후, 고립의 길을 가게 되는 첩경이 됩니다. 공인인증서가 그렇게 탁월한 보안 효능을 가졌다면, 강제하지 않아도 모두들 앞다투어 채용할 것입니다. 강제 규정을 삭제하는 순간 시장이 외면할 저급하고 불편한 기술이라면 더 더욱 그런 기술을 정부가 강제해서는 안될 것입니다.

조승수 의원의 이번 발의는 참으로 의미 있는 일이라고 생각합니다. 조승수 의원이 발의하는 전자금융거래법 개정안이 신속히 통과될 수 있게 각자 자신의 지역구 국회의원에게 이 사실을 알리고 최대한 협조와 이해를 구해 주시기 바랍니다.

mumyoung 님께서 3.11일에 적은 댓글에 언급하신 바 있습니다만, 2009.11.17. 미국 미시간 주 법원에 제기된 Experi-Metal Inc. v. Comerica, Inc. 사건을 소개합니다.

Experi-Metal, Inc. (EMI)는 Comerica Bank 의 기업 고객입니다. 코메리가 은행은 일회용 비밀번호 생성기(OTP 토큰)로 접속 고객을 인증합니다. 2009.1.22. EMI의 경리 직원은 코메리카 은행이 발송한 것처럼 보이는 이메일을 받고 그 이메일에 안내된 대로, 이메일에 제시된 링크를 클릭하여 연결된 사이트(코메리카 은행 처럼 보이는 피싱 사이트)에서 회사의 계정 정보와 OTP토큰에 표시된 비밀번호를 입력하였습니다.

공격자는 그 즉시 이 직원이 입력한 OTP암호로 코메리카 은행에 접속하여 그날 오전 7:30부터 로그인 상태를 유지하면서 오후 2:02까지 총 85회에 걸쳐 러시아, 에스토니아, 스코트랜드, 핀랜드, 중국 및 미국 내의 여러 은행들에 있는 공격자의 계좌로 이체하는 거래를 실행하였고, 그 결과 EMI 의 계좌에서 합계 $560,000 가 빠져나갔습니다.

코메리카 은행은, EMI와 같은 회사에서 경리를 취급하고, 회사 계좌의 접근 수단을 관리하는 인원이라면, 피싱 메일에 링크된 사이트가 코메리카 은행사이트가 아니라는 점을 쉽게 알수 있었음에도, OTP 암호를 입력해 준 것은 잘못이라고 주장하며 배상을 거부했고, EMI는 은행이 그 동안 주기적으로 고객에게 은행 로그인 링크가 포함된 안내 이메일을 발송해 왔으므로, 고객이 이메일에 링크된 사이트를 별 생각 없이 믿도록 “유도”해 왔으니, 은행의 잘못이라고 주장하여 팽팽히 맞서다, 소송으로까지 간 사건입니다.

법리적으로 여러 복잡한 내용이 있으나, 두가지 점만 지적합니다.

첫째, 이 사건은 OTP 기술의 문제가 아니라, 코메리카 은행의 보안설계가 허술해서 생긴 문제라고 생각합니다. 7시간 가까이 공격자가 로그인 상태를 유지하며 85회의 이체 거래를 반복 수행할 수 있었던 이유는, 코메리카 은행이 최초 로그인때에만 OTP 암호 입력을 요구하고, 매 이체거래에는 더 이상의 인증(OTP 암호 입력)을 요구하지 않는 방식으로 설계되어 있었기 때문입니다. 소송이 제기된 이유도 코메리카 은행의 보안 설계가 통상의 합리적 수준에 못미쳤다는 판단을 받을 가능성이 있기 때문이지, OTP가 허술하기 때문은 아닙니다.

둘째, 그동안 금감원은 미국에는 타행이체에 사흘씩 걸린다는 주장을 끊임 없이 해 왔으나, 이런 주장은 EMI v. Comerica 에서 보듯이 사실이 아닙니다. 이 사건의 사고거래는 아침 7:30경에 시작되었고, EMI사는 오전 10시30분 경에 이상 징후를 파악하고 코메리카 은행에 거래 중단을 요청하였다고 주장하고, 코메리카 은행은 정오경에 자신들이 이상징후를 파악하였다고 주장하지만, 어쨋건 이체 거래는 2시까지 계속되었고, 실시간 타행 이체된 부분을 되돌릴 수 없어서 분쟁이 발생한 것입니다.

인터넷에 근거없이 떠도는 주장 중 하나가 “외국은 사고거래가 나면 고객이 뒤집어 쓰게되어 있으나, 우리 나라는 주로 은행이 뒤집어 쓰게 되어 있다”는 것입니다.

법제가 이러니, 한국에는 은행들이 유달리 보안에 신경을 쓸 수밖에 없다는 주장입니다. 물론 금감원 관계자들이 언제나 내세우는 주장이기도 합니다.

우물안 개구리도 이런 개구리는 보기 어렵습니다. 금감원의 무책임/무식도 이런 수준으로 10년을 버텨 왔으니, 제일 먼저, 저같은 법률가가 책임을 통감해야 하겠지요.

외국 어디에도 사고가 나면 고객이 뒤집어쓰는 제도는 없습니다.(도대체 말이 되는 소리를 해야 대꾸라도 할 가치를 느끼지요).

언제나 들먹이는 미국의 법제도를 간단히 소개합니다. Regulation E 라고 알려져 있는 연방법 규정입니다(Electronic Funds Transfer (EFT) Act). 해당 규정은 여기 있습니다.

핵심 내용은

• 접근 수단(접근 매체, 즉 보안카드, 인증서 등을 포함하는 개념)을 분실하였음을 안 날로부터 이틀 내에 은행에게 분실 신고를 하면 고객은 50달러 한도 내에서만 책임을 집니다.
• 이틀이 지나도록 분실 신고를 안 한 경우 500달러 한도에서 고객이 책임을 집니다.
• 거래 내역이 정기적으로 고객에게 전달될 경우, 사고거래가 표시된 명세서가 발송된 날로부터 60일이 지나도록 고객이 은행에게 아무 신고도 안하면 (좀 복잡한 조건이 충족되면) 전액에 대하여 책임을 져야할 가능성도 생깁니다…

보안카드를 분실했다는 사실을 알고도 은행에게 신고를 안한 고객은 어느 정도 책임을 지는 것은 당연하지요. 한국에서도 그럴 것입니다.

하드디스크에 저장된 인증서 파일을 도난(유출)당했는지 안했는지를 알아낼 수 있는 고객은 없습니다. 따라서 고객은 50달러 이상 책임을 질 경우가 사실상 없다고 보시면 됩니다. (분실을 안 날로부터 이틀 안에 신고하면 고객이 보호되므로, 몰라서 신고 못한 경우에도 당연히 보호됩니다) 외국에서 은행들이 인증서를 별로 좋아하지 않는 이유는 바로 여기 있습니다. 아무리 사고가 나도 고객에게 책임을 묻기가 어렵기 때문입니다. 전자서명을 하도록 하면 무조건 고객에게 책임지울 수 있다? 근거 없는 “썰”입니다.

반면에 분실여부를 고객이 당장 알 수 있는 접근수단(보안카드, OTP 발생기, 휴대폰 OTP 의 경우에는 휴대폰)은 은행에게도 유리하고, 고객에게도 안전합니다.

아무 근거 없이 “외국은 사고가 나면 고객이 다 뒤집어 쓴다더라”는 카더라 통신은 좀 그만했으면 좋겠네요. 아무 근거도 없이 그런 말을 자꾸 옮기고 다니는 사람들을 저는 도저히 이해할 수 없네요.

공인인증서 문제가 점점 재미있게 전개되고 있네요. KISA는 웹브라우저에 이미 구비된 인증서 저장/이용 기능이 도저히 사용할 수 없을 만큼 위험하고 불편하다는 전제 하에, 별도 위치(NPKI 폴더)에 인증서를 저장하고, 별도 플러그인으로 인증서를 사용하는 것이 더 안전/편리하다는 주장을 내세우고 있습니다.

한마디로, MS(를 포함한 웹브라우저 제작사들)와 정면으로 한판 붙어 보겠다는 것이지요. MS사가 설계한 웹브라우저의 인증서이용/보안접속 기능이 위험하고 불편하게 설계된 “저질”이라는 소리니까요.

그런데, MS사 입장도 재미있습니다. 자기 웹브라우저의 인증서이용/보안접속 기능이 위험하고 불편하다고 말하자니 그건 좀 안습이고… 웹브라우저의 인증서이용/보안접속 기능이 안전하고 편리하다고 말하자니 별도 플러그인(ActiveX)을 사용할 이유가 없다는 소리가 되고….

웹브라우저를 감싸자니, ActiveX를 버려야 하고, 액티브액스를 감싸고 돌자니 자기 웹브라우저가 (위험하고 불편하게 설계된) 저질 제품이라는 소리 밖에 안되고…

실은, MS사는 이 문제에 대하여 “매우 째째한 방법으로” 입장을 이미 밝힌 바 있습니다. 정상 시력으로는 읽어보기 힘든 “깨알같은 글씨”로 난해하게 적어둔 페이지가 있습니다. http://www.microsoft.com/korea/windows/compatibility/activex.mspx 이 페이지는 제가 그동안 계속 관찰했었는데, 올라갔다, 내려갔다 하기를 몇번 거듭했었던 것으로 기억합니다. 또 내려갈지 몰라서 스크린 샷을 몇차례 떠 두었습니다만, 최근 화면은 아래와 같습니다(일부).

해당 부분은 다음과 같습니다:

ActiveX를 보안과 같이 시스템 레벨에서 사용하는 것은 지양되어야 합니다. 128bit SSL을 비롯한 표준화된 인증 체제, 그리고 암호 발생기 등 다양한 보안 솔루션을 국가적 차원에서 열린 자세로 수용하여, 다양한 플랫폼에서 기 구현되고 검증된 인프라를 활용하도록 하는 것이 바람직합니다. 현재 Internet Explorer는 세계 표준적 보안 기능을 내장하고 있고, 세계 각국의 은행들은 브라우저 내장의 보안 기능을 활용하고 있습니다.

쉽게 설명하면, (1)’보안’ 용도로 ActiveX를 사용해야 한다는 주장은 말이 좀 안된다. (2) 웹브라우저는 이미 훌륭한 보안접속/인증서 이용 기능이 있다. 그러니 SSL+OTP 등 다양한 해법을 수용하라. (3)세계 각국 은행들은 웹브라우저의 보안 기능을 사용하지 한국처럼 ActiveX 떡칠을 하지 않는다.

요컨대, 금융보안연구원이 최근에 ‘비공개로’ 발표한 “해외 인터넷뱅킹 보안현황 조사보고서“의 내용과 같습니다(SSL+OTP). 이제 곧 MS와 KISA 간의 진실 게임이 벌어질 듯.

글자 좀 키울 수 없나요? 회사 덩치에 비하면, 글자는 좀 … (자기 웹브라우저 좋다는 소리 스스로 하기가 그렇게 거북한가요?)

참고로, 현재 스코어는 3:1 입니다.

모질라 재단(파이어폭스), 애플(사파리), 구글(크롬), 오페라의 입장은 굳이 물어볼 필요가 없을 듯.

최근 금융보안연구원에서 “해외 인터넷뱅킹 보안현황 조사보고서”를 발표하였습니다. 오픈웹에 게시되었던 보고서 전문은 금융보안연구원의 요청으로 내렸습니다. 정확한 fact를 널리 알리는 것이 모두를 위하여 도움이 된다고 생각하지만, 누군가 내리라고 했나보죠. ㅋㅋㅋ

저는 내렸습니다만, 손바닥으로 하늘을 가리려는 시도는 요즘 세상에는 무의미 하겠네요. 구글 docs에 있는 자료의 링크

어쨋건, 이 보고서는 미국, 영국, 네델란드, 호주, 싱가포르, 중국, 말레이지아의 여러 인터넷 뱅킹 서비스의 보안 해법을 조사하고, 정확하게 소개하고 있습니다. 요점을 정리하면,

• 암호화 교신은 웹브라우저로 한다(SSL/TLS 로 수행되는 https 접속)
• OTP (일회용 비밀번호)를 사용한다.
• 키보드보안, 안티바이러스, 개인방화벽 액티브액스 플러그인 설치를 강제하지 않는다.

이 모든 나라들의 보안전문가들이 모두 틀렸고, 오로지 공인인증서/ActiveX 강제 방식만이 옳다는 견해는 설득력이 좀 없다고 생각합니다. 공인인증서를 사용하는 방법도 허용하고, https + OTP 방식도 허용하는 것이 합리적이고 중립적인 해결방법이라고 생각합니다.

중소기업 옴부즈만 제도가 있습니다. http://homin.go.kr/ 중소기업의 사업에 장애를 초래하는 불합리하고 부당한 규제를 지적하고, 그 개선을 정부에게 촉구하는 역할을 수행하는 독립 기구입니다. 기업 호민관(Tribune)이 바로 이 역할을 합니다. (트위터 id @minhwalee ) 아시겠지만, 호민관은 로마시대에 평민들의 이익을 수호하고 국정수행의 불합리한 측면을 견제하는 역할을 수행하였습니다.

기업호민관실에서는 금융위원회의 경직된 규제(금융거래에 공인인증서를 반드시 사용하라는 규제) 때문에 여러 기업들이 겪는 고충과 국제경쟁력 약화 실태를 지적하고, 앞으로는 (1)현재대로 공인인증서를 사용하거나, (2)세계 각국의 은행들이 안정적으로 사용하고 있는 https+OTP 방식을 사용하거나 선택할 수 있도록 규제를 개선하도록 건의할 예정입니다.

이 건의는 조만간 관계 장관회의에 상정될 예정입니다. 관심있게 지켜봐 주시기 바랍니다.

국내 전자금융거래가 안고 있는 문제점들을 개선하기 위하여 방송통신위원회가 노력하고 있습니다. 그 노력의 중요한 부분은 불합리한 규제 체제로 인하여 업계(은행, 카드사, 쇼핑몰 등)가 겪는 고충이나 피해의 실상을 정확히 파악하고 이해하는 것입니다.

알라딘, 예스24, G마켓, CGV, 메가박스, 코레일 등은 공인인증서를 사용하지 않고 카드결제를 해왔습니다. PC는 물론(CGV, 메가박스, 코레일) 스마트폰에서도 결제가 신속, 간편, 안전하게 처리되었고, 카드사도 만족스러워했고, 쇼핑몰도 만족스러워 했고, 고객(소비자)들은 열광했습니다. 이들 업체는 경쟁 업체들이 “액티브액스 떡칠, 그 나물 그밥” 결제서비스에 머무는 동안, 참신한 “혁신적 서비스”를 제공하면서 해당 업계의 선도적/진취적 기업으로 소비자의 사랑을 받기 시작하고 있었습니다.

금감원이 스스로 만들어 놓은 현행 규정에도 30만원 미만 상거래에는 공인인증서를 사용할 의무도 없으므로, 이들 업체가 규정을 위반한 것도 아닙니다.

그러나, 금감원은 이것을 중단시켰습니다. 혁신적이고 더 나은 서비스를 제공하는 업체를 압박하고, 카드사들에게 전화를 걸어 결제 서비스를 중단하도록 했습니다. 적지 않은 투자를 하고, 노력을 기울여 서비스를 준비하고 경쟁 업체들보다 더 나은 기술로 소비자에게 더 좋은 서비스를 제공하려는 사업체들에게 금감원이 위법하게(규정에도 없는 이유로) 개입하여 영업을 못하게 함으로써 손해를 가하는 것입니다.

금감원이 이렇게 무법자 행세를 해도 금융사업자들은 꼼짝 없이 당할 수 밖에 없습니다. 금융사업자가 금감원의 위법한 훼방에 대하여 행정소송을 제기하고 정면으로 맞설 수 있다고 생각하십니까? “찍히면 끝장”인 판에? 규정을 아무리 준수하고 정직하게 영업을 해도 금감원이 이유 없이 때리면 맞는 수밖에 없습니다. 무법천지가 따로 없습니다.

방송통신위원회가 해당 사업자들을 초청하여 고충을 청취하고자 하였으나, 금감원은 뒤에서 금융기관들에게 전화해서 이 자리에 참석하지 못하게 하였습니다. 금감원의 이런 전화를 무시하고 방송통신위원회에 출석하여 고충을 털어놓을 수 있는 은행/카드사가 있다고 생각하십니까?

증인 보호 프로그램(witness protection program)이라는 것이 있습니다. 금감원의 무법적 처사를 증언할 금융사업자에게 제일 필요한 프로그램이라고 생각합니다.

금감원은 더 이상 자정 능력이 없는 ‘조직’으로 전락하였다고 생각합니다.

누가 뭐래도 국내 보안업체들은 현재 “아이폰 특수”를 누리고 있습니다.

공인인증서를 사용하라(규정에 있는 내용), 전자서명을 하라(규정에도 없는 내용)는 금감원 요구에 맞추려면 은행/카드사/증권사/쇼핑몰 마다 아이폰앱(app)이 하나씩 필요합니다(아니면, 중계서버를 이용한 공동뱅킹, 공동쇼핑, 공동증권거래 앱? ㅎㅎㅎ).

쇼핑앱, 증권거래앱을 하나 짜주면 약 5000만원-9000만원 가량을 받습니다. 개발 기간? 3주, 길어야 1달 가량. 핵심 개발인력? 두세명 정도.

업체들이 마구 쏟아내는 이런 앱들의 설계 구조, 안전성에 대한 제대로 된 점검은 납품업체도 할 시간도, 여력도 없고, 제3자나 학계도 할 처지도 못되고, 프로그램을 납품받은 증권사/카드사/은행이 할 능력도 없습니다. 아무도 검증하지 않습니다.

금감원은 “공인인증서/전자서명을 사용하기만 하면 안전하다”는 확신에 차 있지만, 사실은 인증서/전자서명이 안전을 제공하는 것이 아니라, 그것을 구현하는 프로그램이 제대로 설계되었지에 따라 안전할 수도 있고 허술할 수도 있습니다.

아무도 검증하지 않는 3주 짜리 인증/서명 앱이 안전한지 누가 확인했나요? 금감원이 확인해 봤나요?

(아이폰) 웹브라우저에도 인증서를 사용하는 기능이 이미 있습니다. 웹브라우저의 인증서 구현기능은 전세계 보안전문가들이 여러해 동안 투명하게 검증하고, 개선하고 있는 것입니다. 3주짜리 앱 보다는 더 안전하다고 저는 생각합니다.

어째서 한국에서는 웹브라우저가 이미 제공하는 인증서 저장/이용 기능을 사용하지 못하도록 하고, 꼭 별도 앱/플러그인을 사용하도록 공인인증서 규격을 만들어 두었는지, 언젠가는 진실이 밝혀 지겠지요.

그리고 금감원은 어째서 “전자서명을 하라”고 (규정에도 없는) 강제를 해대는지도 밝혀질 것입니다.

그 내막은 보안업체/KISA/금감원이 알고 있겠지만, 결국 다른 사람들도 알게 되겠지요.

[간략 version]

하나N뱅크 아이폰앱과 기업은행 아이폰앱을 모두 사용해 보신 분은 아시겠지만, 앱만 설치하면 되는 것이 아니라, 공인인증서도 각 앱마다 반복해서 설치해야 합니다. 아이폰의 설계 구조 때문에 어쩔 수 없습니다.

뱅킹이야, (1)자기가 거래하는 한 두개 은행의 앱을 설치하고 그때마다 공인인증서를 아이폰에 설치하거나, (2)세계 최초 “IT강국 공동 뱅킹” 앱과 공인인증서를 한번 설치하고 여러 은행과 거래하거나 하면, 되긴 되겠지요.

그러나 쇼핑거래(카드결제)에도 전자서명을 하라는 금감원의 지시를 따르려면,

• 각 쇼핑몰 마다 쇼핑 앱을 뿌리고, 고객은 쇼핑 앱과 자신의 공인인증서를 거듭해서 아이폰에 설치하거나 (이런 사태는 “세계 최초”일 듯)
• 카드사 마다 카드결제 앱을 뿌리고, 모든 쇼핑몰이 이 결제 앱 속으로 들어가거나(이건 불가능하겠지요),
• “공동 뱅킹”과 비슷하게, “공동 쇼핑”을 해야 합니다. 한국의 모든 쇼핑 거래가 하나의 중계 서버를 거쳐가야 하는 사태(인류 역사상 전무 후무한 기록이 될 듯)

금감원 담당자는 아이폰을 사용해 본 적도 없거나, 아이폰앱 설계 구조가 어떤지를 전혀 모르는 “아이폰맹”이라는데 10만원 걸겠습니다.

카드 결제에도 전자서명을 하라는 금감원의 황당한 교시는 결국에는 슬그머니 사라지겠지만, “아이폰맹” 공무원의 고집 때문에 허비한 시간은 누가 보상해 주나요?

[Long version]

흔히들 스마트폰은 PC와 “같다”고 하지만, 아이폰은 PC와는 다른 독특한 보안 설계 구조를 채택하고 있습니다. 각각의 앱은 차단된 작동 환경(sandbox)에서 실행됩니다. 예를 들어, A은행 거래를 수행하는 앱은 B은행 앱의 구성 부분을 불러와서 쓸 수 없습니다. 거래내역 전자서명을 하려면 반드시 별도 앱을 사용해야 하고, 각각의 아이폰 앱은 단절되어 작동하므로, 서로 간에 서명 모듈을 공유할 방법이 없습니다. 바로 이렇기 때문에, 금융거래에 “전자서명”을 꼭 하라는 금감원의 거룩한 교시를 따라야 한다면, 아이폰에서는 만족스런 해법이 사실상 없습니다(“공동 뱅킹”, “공동 쇼핑”이라는 공동체주의 방식 외에는).

공인인증서를 아이폰에 저장하고, 그것으로 전자서명 해서 특정 은행/카드사와의 거래를 수행하는 “개별 앱”을 만드는 것 자체는 그리 어렵지 않습니다. 이미 하나N뱅크 앱은 실제로 사용되고 있고, 카드 결제 앱의 시안을 만들어 앱스토어에 등록한 업체도 물론 있습니다. 그러나 카드 결제 앱이 “시안”으로만 남아 있는 이유는 다음과 같습니다.

A카드사가 카드결제 앱을 채택했다고 칩시다. 그러나 많은 쇼핑몰들이 A카드사의 카드결제 앱에 “내장”되지 않으면 이 결제앱은 현실적으로 무용지물입니다. 그렇다고 해서 쇼핑몰마다 카드결제 앱을 만들어 앱스토어에 등록하고 고객들에게 뿌려야 하는 사태도 비현실적입니다. G마켓 정도의 규모가 되는 쇼핑몰이야 별도 앱을 뿌릴 수 있겠지만, 수천개의 쇼핑몰들이 제각각 별도의 앱을 뿌린다? ㅎㅎㅎ (보안업체에게는 사상 최대의 활황이요, 축복이겠지만)

신용카드를 여러개 사용하고자 하는 고객은 카드사별로 카드결제 앱을 거듭 내려받아 설치해야 합니다.

카드사 숫자 x 쇼핑몰 숫자 만큼의 카드결제 앱을 아이폰 앱스토어 등록하면, 아마도 세계 토픽거리는 되겠지만, 그저 웃음 거리에 불과할 것입니다.

앱만 설치하면 되느냐? 아닙니다. 그때마다 공인인증서도 거듭해서 아이폰에 또 다시 설치 해야 합니다. A카드사의 X쇼핑몰 결제 앱에 사용되는 공인인증서는, B카드사의 Y쇼핑몰 결제 앱이 불러와서 쓸 수가 없습니다. 하나N뱅크 앱과 기업은행 아이폰 뱅킹 앱을 둘 다 사용해 보신 분은 아실 것입니다.

바로 이렇기 때문에 “공동뱅킹 앱”이라는 기상천외한 “세계최초”의 발상이 나오는 것입니다. 공동뱅킹 앱을 하나 설치하고, 공인인증서도 한번만 아이폰에 저장하면 여러 은행의 거래를 할 수 있게 하자는 것이지요.

물론, 뱅킹이야 은행 수도 몇개 안되니까 공동뱅킹을 하건, 각 은행별로 앱을 뿌리건, 어찌해 볼 수 있겠지만, 쇼핑은 정말 대책이 없습니다.

USIM 칩에 공인인증서를 저장하고 전자서명하면 된다는 “설”이 요즈음 나도는 것 같습니다. 이것이 가능하려면, 현재 보다 더 큰 용량의 USIM 칩이 새로 배포되어야 할 뿐 아니라, 애플사가 아이폰의 사양을 바꾸어 USIM 칩에 개인인증서를 저장하고 사용하는 기능(PKCS#11 지원)을 아이폰 OS에 탑재해 줘야 합니다. 대용량 USIM 칩이야 우리가 뿌리면 되지만, 애플사가 PKCS#11 지원을 아이폰 OS에 추가해 줄까요?

아이폰은 다른 방식으로 개인인증서를 이미 지원하고 있습니다. 아이폰에는 개인인증서를 저장하고, 그것으로 “클라이언트 인증 https 접속”을 하는 기능이 있습니다. 그러나 거래 내역 전자서명 기능은 없습니다. 한국처럼 거래내역 전자서명에 집착하는 나라는 없고, 거래 내역 전자서명은 어차피 “세션 보안”을 제공하는 것도 아닙니다. 한마디로 한국 외에는 별 수요도 없는 기능입니다.

애플사가 한국만 쳐다보고 장사하는 곳이었다면, 당장 지원했었겠지요….

언제까지 그 잘난 전자서명을 고집하다 포기하는지를 그저 씁쓸한 심정으로 지켜볼 따름입니다… WIPI도 그랬지요. 쉬엄 쉬엄 갑시다. 이미 IT 강국이니까.

ps. 세계에서 80번째로 아이폰을 도입해 놓고, 어리버리 하는 광경이 딱하기도 하고… (아이폰맹 금감원에 대해서는 더 이상 할 말이 없습니다. 잘 해보시기 바랍니다)

기본으로 돌아와서 생각해 볼 필요가 있습니다.

인증서/전자서명이 더 나은가? usim 이 더 나은가? 심지어 biometric 정보(홍채, 지문 정보 등)로 인증을 하는 것이 더 나은가? 복잡하지요. 그러나 대답은 간단합니다. 이런 문제를 금감원이 판단하고 결정해줘야 할 필요는 없다는 것이 아마도 정답일 것입니다. 보안전문가들 사이에도 어느 인증 기술이 절대적으로 우월하다는 견해는 없습니다.

고작해야, single-factor 인증 보다는 multi-factor 인증이 더 우월하다는 것이고, 공인인증서는 multi-factor 인증 기술 중 “하나”에 불과합니다.

금감원이 무슨 “기술”을 사용하라고 은행을 대신해서 결정해 줄 필요는 없습니다(불행하게도 지금껏 금감원이 이렇게 해 왔고, 그것이 문제의 근원입니다). 이미 여러 기술이 국내/외에 존재하고 국외에서는 사용되고 있지만(바르셀로나 MWC에 가보신 분들은 직접 목격하셨을 것입니다), 금감원 규제 때문에 이런 기술이 국내 시장에 들어오지 못하도록 막혀있으니까 문제가 생기는 것입니다.

금감원은 “특정한 인증 기술”만을 사용하라는 식으로 규제할 것이 아니라, “결과(performance)”를 기준으로 규제하면 됩니다. 어떤 기술을 쓰건 사고가 안나면 장땡입니다. 전자서명을 아무리 해도 사고가 자꾸 나면 무슨 소용이 있겠습니까? 그러니, 기술 선택은 각 금융사업자가 최선의 판단으로 결정하게 하고,

1. 금감원은 사고거래 내역을 통합 관리하고(지금은 모두들 숨기고 있습니다; 그러나 사고거래신고 통합센터를 금감원이 운영하면 은행들이 숨길 수가 없습니다. 모든 은행, 카드사, 쇼핑몰 홈페이지에 사고거래 신고센터 링크를 배치하면 되지 않을까요?)
2. 사고가 많이 나는 금융사업자를 문책하고 그 명단을 공개(그래야 소비자가 보호되지 않겠습니까?) 하면 충분합니다.

규제를 하지 말자는 것도 아니고, 공인인증서가 나쁘다는 것도 아닙니다. 자율과 책임을 적절히 조화해서 합리적으로 규제하면 모두에게 이롭게 된다는 것입니다.

댓글을 다신 어느 분께서 말씀하신 내용이 주목받아야 한다고 생각하여 본문으로 소개합니다. 해당 부분을 인용하면,

금융 사고나면 은행이 손해날텐데… 은행이 알아서 좋은 것을 선택하게 하면 안되나요? 국가는 국민의 편에 서서 사고가 많이 나는 은행을 감독하구요. 이거 못하나요? 안하나요?

공인인증서는 여러 인증 기술 중 하나에 불과합니다. 좋은 기술이고, 유용한 기술입니다. 그러나 그것만이 절대적으로 우월한, 전무후무한 인증 기술이라고 생각하는 전문가는 없습니다. 나름의 한계도 있고, 실제로 어떻게 운용되느냐에 따라서 그 보안효능이 미미할 수도 있습니다.

“공인인증서를 반드시 쓰라”고 강제하지 말고, 금융기관이 각자 최선의 판단으로 자신의 서비스 성격에 상응하는 적절한 인증기술을 선택하여 업무를 수행하도록 자율을 부여하고, 사고가 많이 나는 은행을 특별관리하면 무슨 어려움이 있습니까?

공인인증기관과 인증 프로그램 판매 업체의 이권은 타격을 받을지 모르겠으나, 국민 전체의 이익이 이들 개별 업체의 이권보다는 소중하지 않겠습니까? 그리고, 공인인증서가 과연 그렇게 좋다면 강제하지 않아도 모두들 앞다투어 채용할 것이므로 인증 프로그램 판매 업체가 장사 안될까봐 불안에 떨 필요도 없지 않겠습니까?

금감원이 파워를 잃는 것도 아니지요. 사고가 많이 나는 관리 대상 은행을 “엄격히” 꾸짖을 정당한 파워가 생깁니다. 지금 체제는 모든 금융기관이 “보안성 심의” 단계에서 금감원 실무자에게 파리 목숨처럼 벌벌 기게 만드는 것인데, 이것이 과연 누구를 위해서 좋은지, 과연 정당한 파워인지 곰곰히 생각해 볼 필요가 있겠네요.

잘하는 은행은 더욱 잘하도록 풀어주고, 못하는 은행을 철저히 감독하는 것이 금감원의 임무라고 생각합니다. 모든 금융기관을 전부 벌벌기도록 만드는 것은 힘있고 양식있는 감독기관이 할 짓은 아니겠지요.

자율과 책임의 조화가 필요할 듯 싶습니다. 자율을 박탈해 놓고 책임을 묻겠다는 금감원의 태도는 보기에 좀 거북하군요…

17개 시중은행은 지난해 “모바일 금융협의회”라는 것을 만들어 “스마트폰 기반의 모바일 뱅킹 서비스 공동 구축 사업”을 추진했고, 이 작업은 금융결제원이 담당하여 수행했습니다. 이제 그 개요가 공개되었습니다. 아래 그림 참조.

요컨대, 고객은 공동뱅킹 앱을 자신의 단말기에 하나 설치하고, 이 앱을 통하여 직접 자신의 은행과 교신하는 것이 아니라, “공동모바일 서버”를 거치고, 이 중계서버가 해당 고객의 은행과 교신하고, 그 결과를 고객에게 던져주는 방식을 채택하겠다는 것입니다. 그러니, 모든 은행들은 여기에 들어오라는 것입니다.

한마디로 끔찍한 발상입니다. 공동모바일 서버에 장애가 생기면 참여은행 모두의 뱅킹 서비스가 일시에 중단되고, 공동모바일 서버가 침입공격을 당하면(“절대로 안전한” 서버라는 것은 세상에 존재하지 않습니다) 모든 참여 은행과의 거래가 고스란히 공격에 노출됩니다.

그리고 고객의 금융거래 정보는 중계서버를 관리하는 자의 통합 콘트롤 하에 있게 됩니다. 그 서버를 누가 운영하는지는 모르겠습니다만, 나는 내가 거래하는 은행을 믿는 것이지, 그 중계서버 운영자를 믿을 수는 없습니다. 중계서버 운영자가 나쁜 마음을 먹을 것으로 가정할 필요는 없겠지만, 수사 당국은 앞으로 중계서버를 압박하면 (영장을 발부받을 수도 있겠지요), 온갖 금융거래 정보를 다 입수할 수 있게 될 것입니다.

개별 은행이 자신의 고유한 신상품을 개발하는 경우라면 물론 비밀리에 추진하고 깜짝 공개하여 마케팅/선전 효과를 거두는 것이 당연합니다(하나N뱅크 앱 같은 경우가 그렇습니다). 그러나, 17개 시중은행이 공동으로 (거의 전국민의 전자금융거래에 영향을 미칠) 어떤 해법을 고안하는 과정이 이런식으로 아무런 논의도, 검증도 없이 밀실에서 일방적으로 추진되고, 그 결과는 비전문가가 보더라도 졸렬한 수준에 머무는 사태는 자못 절망적입니다.

이것이 “모바일 뱅킹 컨버전스”인가요? “마구 때려서 우겨넣기”가 컨버전스는 아니겠지요.

올해 4월부터 순차적으로 서비스가 개시될 예정이라는데, 만일 저의 거래은행이 이런 황당한 “공동 뱅킹”을 저에게 강요한다면, 저는 하나은행으로 갈아타겠습니다.

최근 불거져나온 “세계 최초 아이폰 백신 소동“은 그저 웃어 넘길 일은 아닙니다. 세계의 기술 트렌드로부터 고립되어 특이한 해법과 미봉책으로 일관해 오던 국내 보안/거래 솔루션 업계의 실상과, 정확한 전문 지식 없이 선정적 보도로 일관해온 국내 일부 기술 매체들의 수준을 드러내 주는 “상징적 사건”입니다.

이 사건을 계기로 그동안의 전자금융 감독 체제가 과연 바람직했었는지를 되짚어 볼 필요가 있습니다. 다음과 같은 기본 원칙들을 다시 한번 음미해 보시면 좋을듯 합니다.

1. 금융, 보험 서비스의 공공성

금융, 보험 서비스는 많은 소비자의 이해 관계에 큰 영향을 미치는 것이므로 규제의 필요성이 분명히 있습니다. 사기업에 불과하므로 시장 논리에 방임해 둘 수 밖에 없다는 주장은 천박한 논리일 뿐 아니라, 금융 보험 서비스의 근본 성격에 대한 몰이해를 노출하는 것입니다. 요컨대, 규제의 필요성 자체는 분명하지만 구체적으로 어떻게, 어느 수준에서 규제하는 것이 옳은지에 대한 고민이 필요할 것입니다.

2. 규제와 자율의 조화

사업자의 단기적/개별적 이익과 공동체의 장기적/거시적 이익이 합치하지 않는 영역에서는 강력한 규제가 필요합니다. 예를 들어, 서브 프라임 모기지와 같이 고 위험/고 수익 사업 아이템의 경우, 개별 사업자의 단기적 이익 추구를 방임할 경우, 전체 시스템의 리스크는 감당하기 어려울 만큼 커지게 됩니다. 눈 앞의 이익 추구는 누구나 원하는 것이므로, 이것을 자율에 맏겨둘 수는 없고 규제를 통하여 전체의 손해 발생을 예방하는 것이 바로 금융감독 당국의 임무라고 생각합니다.

그러나, 사업자의 단기적 이익과 공동체의 장기적 이익이 합치하는 영역에서는 과연 규제의 필요성이 있는지를 좀더 면밀히 검토해야 할 것입니다. 개별적 이해관계와 공동체의 거시적 이해관계가 일치하는 분야에서 함부로 규제의 칼날을 들이댈 경우 개별 사업자에게도 해롭고, 공동체의 전체적 이익마저도 저해할 가능성이 있습니다.

전자금융거래 보안이 바로 이런 부문입니다. 허술한 보안 선택을 하는 사업자는 당장에 자기 자신에게 손해가 돌아옵니다. 전자금융거래법은 전자금융거래 사고가 발생하면 고객의 고의나 중대한 과실을 사업자가 입증하지 못하면 사업자가 배상 책임을 지도록 규정하고 있습니다(제9조). 보안을 강화하고 전자거래를 안전하게 설계하는 것은 개별사업자의 목전의 단기적 이익에도 부합하고, 모든 사업자들과 소비자들의 거시적, 장기적 이익에도 부합하는 것입니다.

요컨대, 전자금융 거래 보안은 규제당국이 개입하지 않더라도, 개별 사업자가 스스로의 단기적 이해관계 때문에라도 사고발생을 줄이고 싶어하는 영역입니다.

3. 규제 과잉의 폐해

규제가 필요 없는 영역에 규제 당국이 개입할 경우, 과잉규제의 폐해가 다음과 같이 나타납니다:

(1) 경쟁이 저하됩니다. 국내 금융기관들은 하나같이 ActiveX 플러그인을 사용한 해법을 똑같이 채택하고 있습니다. 모두들 그저 “금감원이 하라는 대로만 하면 된다”는 태도를 견지하고 있습니다. “이용자PC에 보안프로그램을 설치”하라, “공인인증서를 사용하라”는 등의 경직된 규정을 애초에 두지 않았더라면 국내 금융기관들 중, 적어도 일부는 벌써 ActiveX 플러그인을 걷어내고, 더욱 진전된 보안 해법을 채택하여 사업을 펼치고 있었을 것입니다. 국내의 보안 업계도 미국, 유럽, 이스라엘, 호주 등 세계 유수의 보안 솔루션 사업자들과 경쟁하는데 필요한 기술력 확보를 위한 노력을 기울였을 것입니다. 공인인증서와 ActiveX가 최상의 탁월한 해법이라면 강제 규정이 없더라도, 누가 시키지 않아도, 업계가 스스로 채택하고 있을 것입니다.

(2) 혁신이 저하됩니다. 규제는 사업자에게 부담으로 작용하기도 하지만, 다른 한편으로는 경쟁과 혁신의 고통을 덜어주기도 합니다. 국내 은행들은 모두들 규제 당국을 원망하면서 고만고만한 똑같은 해법으로 현상 유지를 하면서 현재의 시장 구도에 안주하고 있습니다. 겉으로는 불평을 늘어 놓지만, 한편으로는 편안함을 누릴 뿐 아니라, 심지어는 혁신적 뱅킹 사업을 추진하고 준비할 인력 조차 마련하지 않고 있는 실정입니다. 실제로 일부 시중 은행들의 e-business 사업단은 파이어폭스가 무엇인지도 모르는 ‘컴맹 e-business 사업단장님’께서 군림하는 한가한 부서일 뿐입니다. 새로운 어떤 경쟁 사업자가 혁신적 뱅킹 솔루션을 선보이면서 기존의 시장 구도를 뒤흔드는 “피곤한” 사태가 생길 가능성이 봉쇄되어 있기 때문입니다. 최근 선보인 하나N뱅크 앱에 대하여, 가장 큰 불평과 볼멘 소리를 쏟아 낸 자들은 바로 국내 은행들입니다. 편안히 장사해 오고 있는데 왜 피곤하게 만드냐는 것이지요.

(3) 서비스의 질이 저하되고 소비자가 피해를 입게 됩니다. 온국민들이 자기 컴퓨터에 ActiveX를 덕지덕지 설치하긴 했지만, 그래도 그럭저럭 잘해왔지 않느냐? 라고 반문하실지 모르겠습니다. 그러나 바이러스에 감염된 좀비 컴퓨터의 비율이 세계에서 가장 높은 축에 속하는 현 사태는 한마디로 전국민이 입은 막대한 피해입니다. 외국은 계좌이체를 하려면 이틀 사흘이 걸리지 않느냐? 라고 반문하실지 모르겠습니다. 유럽, 호주를 가보십시오. 하다 못해 이웃 일본을 살펴 보십시오. 우물안 개구리가 꿔왔던 자화자찬의 긴 꿈에서 빨리 깨어나지 않으면, 앞으로 제2, 제3의 “세계 최초 아이폰 백신 소동”이 계속 벌어질 것입니다.

실제로 사고를 잘 막아 오긴 했습니까? 이점이 바로 모든 금융소비자들이 궁금하게 여기는 점입니다. 아래 설명드리는 규제 당국의 역할과 개입이 시급하고도 절실히 필요한 분야가 바로 여기입니다.

4. 투명성 제고

각 금융기관별 전자금융 사고 발생 빈도, 발생 규모, 사고의 유형에 대한 정확한 자료가 있습니까? 모두들 사고발생을 조용히 덮고 적당히 무마하고 넘어가려 하고 있습니다. 이것이 과연 누구를 위해서 도움이 됩니까? 지금까지 정말 잘 막아 왔다면, 사고발생 내역을 투명하게, 자랑스럽게 공개하지 못할 이유가 없습니다. 실제로 우려할 만한 수준의 사고가 발생하고 있다면, 더더욱 이 사태를 숨겨서는 안될 것입니다.

각 금융기관이 자발적으로 자신과 관련된 사고거래 내역을 규제 당국에 정직하게 신고하기를 기대할 수는 없습니다. 그러나 이 문제를 훌륭하게 해결하는 손쉬운 방법이 있습니다.

사고거래가 발생하면 피해자(라고 주장하는 소비자)는 해당 금융기관에 항의하거나 소비자 단체에 호소하거나, 그래도 잘 해결되지 않으면 언론사 기자를 어렵게 접촉하여 기사화 시키는 등의 “매우 힘겨운 싸움”을 벌여야 합니다. 거대한 은행과 개인이 1대1로 맞서는 상황에서, 서로 기싸움과 힘겨루기가 벌어지는 현재와 같은 사태는 시급히 교정되어야 합니다.

앞으로는, 전자금융 사고 신고 및 피해 보상 요구 절차를 금융감독원이 일괄 관리할 필요가 있습니다. 금감원이 분쟁에 직접 개입하라는 뜻이 아닙니다. 금융기관의 홈페이지 초기화면에는 전자금융 사고신고/분쟁조정 링크를 제시하도록 하고, 소비자가 이 링크를 누르면, 금융감독원이 운영하는 전자금융사고 통합 신고 페이지로 연결되도록 하십시오. 피해자가 여기에서 사고거래의 상세한 내역을 입력하면, 금융감독원은 그 내용을 파악한 다음 해당 은행에 이첩하고, 분쟁 처리 과정을 모니터하면 될 것입니다.

이 작업은 진작에 금융감독원이 당연히 했어야 할 금융 소비자 권익보호조치의 중요한 내용이라고 생각합니다. 이렇게 수집된 정보를 규제 당국은 적절하고 합리적인 수준에서 투명하게 공개해야 합니다. 그래야 소비자들은 어떤 은행의 해법이 저열한지를 합리적으로 판단하고, 적절한 선택을 할 수 있습니다.

사고거래 발생과 관련된 정보가 제대로 관리되고 투명하게 공개되면, 모든 금융기관은 최선을 다해서 안전한 기술선택을 할 것입니다. 사고거래의 유형이 이렇게 잘 정리되고 분석된다면, 예방 대책을 마련하는 일도 더욱 효과적으로 수행될 수 있을 것입니다. 더이상 금융감독원이 보안기술의 상세한 내용에 대하여 이래라 저래라 지시하고, 명령할 필요도 없습니다. 굳이 외국의 사례를 인용하지 않겠습니다. 이와 유사한 수준의 투명한 정보 공개를 통하여 전자금융서비스의 안전을 합리적으로 관리하는 나라는 이미 있습니다. 그런 나라의 금융감독 당국은 보안기술의 상세한 내용에 대하여 경직된 규정을 들이대지 않습니다.

소비자와 사업자의 합리적 판단을 존중하는 것이야 말로 전자금융 보안을 확보하는 가장 올바른 길입니다. 합리적 판단에 필요한 정확한 정보를 제공하는 일은 바로 규제 당국의 몫입니다.

5. 금융감독원에 거는 기대

최근 발표된 스마트폰 전자금융 보안대책은 종래의 PC 전자금융 보안대책에 비하면 획기적으로 진전된 바람직한 내용을 담고 있다고 생각합니다. 종래와 같이 “이용자PC에 보안프로그램을 설치”하라는 식의 특정기술 편향(플러그인 편향)의 표현도 이제는 사라졌고, “공인인증서를 사용”하라는 식의 경직된 표현 대신에 “전자서명 등”을 사용하라는 보다 유연한 정책 기조를 담고 있습니다.

무엇보다도 “취약점 모니터링 체제”를 도입하겠다는 부분은 훌륭한 정책 선택이라고 생각합니다. 취약점 모니터링은 사고거래의 유형을 분석하는 작업을 당연히 전제하는 것이며, 위에서 제안드린 전자금융 사고 통합신고 체제를 이미 구상하고 계시는 것으로 보입니다. 스마트폰 전자금융 보안대책과 같이 (1) 유연하고 중립적인 보안 기준(입력정보 보호대책, 악성코드 예방대책 등)을 제시하고, (2) 취약점 모니터링을 통하여 각 사업자의 performance 를 합리적 수준에서 투명하게 공개하는 정책 방향은 조만간 PC전자금융 부문에도 동일하게 적용되는 것이 바람직하다고 생각합니다.

과거에 채택된 정책에 대하여는 지속적, 상시적 평가가 이루어져야 함은 당연하고, 그 정책의 미비점이 발견되면 신속히 수정하시는 것이야 말로 현명한 규제 당국의 선택일 것입니다.

전자금융거래와 관련하여 그동안 철저히 외면되었던 소비자의 알권리에 대해서도 이제는 관심을 가지실 때 입니다.

지난 1월21일 국내 일부 언론은 정보보호 업체인 NSHC가 안티바이러스 프로그램 개발 업체인 하우리(주)와 공동으로 ‘아이폰 전용 백신 프로그램’을 세계 최초로 개발했다고 보도하였다. 그러나 이 업체가 개발하였다는 프로그램은 앱 스토어에 등록되기는 커녕, 바로 다음날 등록 신청마저 신속히 거부되었다.

아이폰 운영체제의 설계 원리를 이해한다면, ‘아이폰 전용 백신’이라는 개념 자체가 성립되지 않는다는 점을 알 수 있다. 안드로이드 운영 체제와는 달리 아이폰 운영체제는 음악재생을 제외하고는 멀티태스킹(multi-tasking)을 허용하지 않는다. 그뿐 아니라 아이폰의 프로그램 실행환경은 철저히 고립/차단된 sandbox 내부이므로, 어떤 프로그램이 다른 프로그램의 실행 프로세스에 간섭하거나 개입할 여지가 없다. 이렇게 설계된 운용 환경에서 안티바이러스 프로그램을 실행한다는 것 자체가 그다지 설득력이 없을 뿐 아니라, 애플사는 자사가 직접 관리하는 앱 스토어를 통해서만 프로그램이 아이폰에 설치될 수 있도록 하고, 앱 스토어 등록 신청 과정에서 프로그램을 사전 점검하여 악성 프로그램은 애초에 등록되지 못하게 함으로써 아이폰 운용 환경의 안전을 담보하고 있다.

바이러스가 아예 침입할 수 없도록 관리되는 환경에서 안티바이러스 프로그램 설치를 운운하는 것 자체가 코메디일 뿐 아니라, 애플사가 회사의 명운을 걸고 전세계에 판매하는 아이폰 운영체제의 신뢰성 자체에 대한 근거없는 모욕이다. 만일 아이폰용 ‘안티바이러스’ 프로그램을 애플사가 승인한다면, 그말은 곧 바이러스가 포함된 프로그램들이 앱 스토어에 마구 등록되는 사태가 이미 발생하였다고 시인하는 꼴이다. 애플사가 망하기 전에는 이런 일이 벌어질 가능성은 없다.

“세계 최초”에 열광하는 국내의 일부 성향을 적절히 자극하면서, 기술적으로나 논리적으로 터무니 없는 업체의 선전 자료를 검증 없이 베껴 적는 기사, 바로 다음날 등록신청이 거부되었다는 사실은 조용히 덮고 정정 보도조차 내지 않는 무책임함은 안타깝게도 국내 기술언론 매체의 부끄러운 현주소이다.

유사한 사태는 사실 그동안 거듭 반복되었다. 이른바 ‘리눅스용 안티바이러스 프로그램’ 소동이 그것이다. ‘윈도우’가 운영체제인지 컴퓨터인지도 잘 모르던 과거의 규제당국이 전자금융거래에는 백신프로그램을 우선 설치하라는 규정을 도입하자, 국내 일부 보안업체는 ‘리눅스용 백신프로그램’이라는 것을 개발하였다고 발표하는 사태가 벌어졌었다. 문제의 프로그램 개발에 관여하였다는 분의 주장은 “리눅스 운영체제에서 작동하는” 안티바이러스 프로그램은 공개소스로 이미 존재하며(예를 들어 clamAV), 자신은 이것에 기반하여 제품을 만들었다는 것이다.

놀라울 뿐이다. “리눅스에서 작동하는” 안티바이러스 프로그램은 리눅스 이용자를 공격하는 바이러스 프로그램(그런 바이러스가 전파될 가능성은 애초에 희박하다)이 있다는 말이 아니라, 윈도우 이용자들을 공격하는 악성 프로그램을 리눅스 운영체제로 가동되는 메일서버, 파일서버가 스캔해 주는데 사용되는 프로그램들이다. 이메일 서버들은 흔히 리눅스 운영체제로 구축되는 경우가 많다. 이런 메일서버들이 이메일 수령자들에게 전달될 첨부파일을 일괄 스캔하여 악성코드가 포함된 첨부파일은 아예 이메일로 전달되지 않도록 예방하는데 사용되는 프로그램들인 것이다. 이런 프로그램을 개인 컴퓨터에 설치하겠다는 발상은 리눅스가 무엇인지, 클라이언트/서버가 무엇인지 기본 개념 부터가 없거나, 영어를 해석할 능력조차 없는 수준의 인력이나 해낼 수 있는 발상이다. 그런 보안업체의 보도자료를 그대로 베껴적는 IT기자가 수두룩하다는 것이 바로 “IT 강국” 한국의 현실이다.

국내에서는 심지어 ‘리눅스용 키보드보안 프로그램’이라는 것이 실제로 배포되기까지 하는 실정이다. 그야말로 “세계 최초”일 뿐 아니라, “세계 최후”의 발상일 것이다. 리눅스 운영체제에서는 이용자의 계정 암호 없이는 컴퓨터를 아예 사용할 수 없는 것이 보통이고, 키보드 입력값을 가로채는 프로그램이 설치되려면, 계정암호 뿐 아니라, 루트(관리자) 암호까지도 이미 공격자가 입수한 사태가 벌어져야 가능한 일이다. 루트 암호가 유출되었다면 키보드보안 프로그램 따위를 설치해 둔다고 해서 무슨 소용이 있겠는가? 장례식장에서 고인에게 감기약 복용을 권하는 꼴일 뿐이다.

“세계 최초” 아이폰 백신 소동은 세계에서 철저히 고립된 국내 보안업체와 국내 기술매체의 수준을 적나라하게 드러내 보여주는 씁쓸한 에피소드로 기억될 것이다.

금융감독원의 스마트폰 보안 정책 중, “입력정보 보호대책”은 대략 다음과 같은 방향을 생각해 볼 수 있습니다.

기본 개념

• 고객이 입력할 인증 정보의 성격/종류/기술적 특성을 분석하여 대처할 필요가 있습니다.
• 인증 정보 중, 고정값과 변동값을 적절히 구분하고, 그에 따른 대응책을 마련합니다.
• 입력을 요구할 인증정보의 종류 및 빈도를 합리적으로 분석, 결정할 필요가 있습니다.

키보드보안 프로그램만 설치하면 만사해결이라는 황당한 태도는 아마추어리즘의 극치라고 밖에는 달리 표현할 길이 없습니다.

1. 인증서 암호

• 웹브라우저의 보안저장장치(secure key store) 또는 하드웨어적 보안장치(보안토큰)에 인증서를 설치하고 사용할 경우(표준적 방법), “인증서 암호”는 아예 존재하지 않습니다.
• 웹브라우저/하드웨어 보안장치 접근에 필요한 암호는 해당 machine 에만 적용되는 것이므로 유출되어도 인증서의 보안성에 영향이 없으며, 이용자의 컴퓨터 자체에 대한 공격과도 무관합니다.
• 요컨대, 표준적 방법으로 인증서를 사용하면, 인증서 암호라는 것을 아예 입력할 필요가 없어집니다.
• 하드디스크나 USB의 NPKI폴더 안에 일반 파일 형태로 저장된 인증서는 이용자가 자진 삭제하도록 안내, 유도하면 보다 안전한 인증서 운용 환경이 마련될 것입니다.

공인인증서가 국내에서 불러일으킨 엄청난 문제는 일차적으로 KISA에게 책임이 있습니다. KISA는 시급히 인증서 저장 규격을 개선/개정해 주시면 좋겠습니다.

2. 보안카드 번호

• 보안 카드는 소지 수단(possession-based means of access)으로 기능하며, 일종의 OTP (일회용 비밀번호)에 해당합니다.
• 그러나, 앞 두자리, 뒷 두자리로 나누어 합계 4자리 숫자의 입력을 요구하는 현재 방식은 공격자가 요구값의 패턴을 비교적 쉽게 유추할 수 있는 열악한 운용방식이므로, 이것을 수정할 필요가 있습니다.
• 예를 들어, 매 거래 마다 무작위로 지정된 연결되지 않은, 합계 3자리 숫자만 입력하게 할 경우, 노출값은 적어지고 요구값의 패턴은 획기적으로 그 경우의 수가 많아지므로, 공격자가 보안카드의 전체 정보를 고객의 입력값(노출값)으로부터 역으로 유추하는 작업이 비현실적으로 됩니다. 여기 참조.
• 보안카드 운용 방식을 적절히 개선할 경우, 키보드 보안 프로그램은 불필요 합니다.

3. 계좌이체 비밀번호

• 이미 유출되었을 가능성이 가장 큰 인증정보입니다. 오랫동안 각종 신청 서류에 계좌이체 비밀번호를 아예 기재한 적도 있고, 그 후에도 그 정보를 그대로 유지하는 고객의 비율도 높습니다.
• 신용카드 결제의 경우, 카드 비밀번호 첫 2자리를 입력하게 하는데, 이 번호와 계좌이체 비밀번호 첫 두자리가 동일한 경우도 많습니다.
• 계좌이체 비밀번호는 낮은 수준의 신뢰성을 가진 인증정보이므로, 낮은 수준의 보호대책인 화상 키보드로 대처하면 적절할 것입니다. 장기적으로, 금융PIN(6자리)을 사용하고 계좌이체 비밀번호는 인터넷 뱅킹에서는 사용을 중단하는 방안을 검토할 필요가 있습니다.
• 금융PIN 을 사용할 경우, 매 거래마다 무작위로 선택한 3개의 숫자(예컨데, 넷째, 첫째, 둘째; 그 다음 거래에는 둘째, 다섯째, 여섯째 등)만을 입력하도록 설계할 경우(영국 HSBC가 채용하는 방법), 키보드보안 프로그램은 별 필요가 없습니다.

4. 인증정보 입력 요구 빈도

• “안전한 것 같은 느낌이 들게”하는 것과, 실제로 안전한 것은 구분할 필요가 있습니다.
• 암호 입력을 자주 요구하면 할수록 공격의 기회는 늘어납니다. 무지한 고객은 암호입력창이 자꾸 뜨면, 꼬박꼬박 입력하면서 해당 서비스가 “안전하게 설계된 듯한 느낌”을 가질 수는 있으나, 합리적 고객은 저열한 설계에 대한 반감을 가지게 됩니다. 그리고, 모든 이용자들이 공격에 더욱 노출될 뿐입니다.
• 거래 개시에 필요한 인증 단계를 통과한 고객에게 그 세션 중 이루어지는 개별 거래에 대하여 또다시 암호 입력, 인증/서명 등을 거듭 요구하는 것은 무의미 합니다. 거래 세션 개시에 필요한 인증 수단을 구비한 자라면 해당 세션 중 아무리 여러번 암호 입력, 인증/서명을 거듭 요구해도 그 과정을 모두 통과할 수 있습니다. 노출되는 입력 정보만 많아질 뿐입니다.
• 본인이 자리를 비운 사이에 다른 자가 거래할 가능성에 대한 차단은 일정 기간(약 5분?) 입력이 없으면 세션을 종료하는 방법으로 대처하는 것이 옳습니다. 금융거래 세션을 열어두고 자리를 비우는 행위 자체가 “중대한 과실”에 해당할 여지가 많으며, 그로 인한 거래는 그자가 책임을 지는 것이 옳다는 주장은 법원도 쉽게 수긍할 것입니다.

그저 암호입력창만 자꾸 띄워주면 더 안전하지 않을까하는 소박, 유치한 수준의 설계에 길들여져 있는 분들은 제대로 설계된(실제로 안전한) 전자금융거래를 접하시면 “일종의 불안감”을 느낄 수도 있습니다. 너무 간편, 신속하기 때문입니다.

뱅킹 거래 한번하려면, 온갖 프로그램을 설치하고, OK를 무수히 누르고, 웹브라우저를 몇번이나 재시작 하고, 심지어는 컴퓨터를 재 부팅 까지한 다음, 로그인을 하고, 이체할 때마다 무슨 인증서 암호 입력창이 또 뜨고 … 한 마디로 “생 쑈“를 해 온 나머지, 적지 않은 이용자들은 “이렇게 복잡하고 어려우니 안전하지 않을까?”하는 “느낌”을 가지게 됩니다. 그러나 이것은 학대받아온 일반 이용자의 “자기 위안”에 불과할 뿐, 보안기술적으로는 어디 내놓기 부끄러운 수준입니다.

몇 분께서 인증서 로그인 https 접속 방식(오픈웹 방식)의 “보안 기능”에 대하여 댓글을 통하여 질문하셨습니다. 오픈웹의 입장은 다음과 같습니다.

1. 인증서 로그인의 기술적 구조

인증서 로그인 https 접속은 고객의 전자서명 없이는 이루어 질 수 없습니다. 접속이 이루어지는 과정에서 고객은 서버가 보내온 어떤 값을 자신의 개인키로 전자서명해서 서버에게 보냅니다(CertificateVerify Message 전달 단계). 서버는 이 전자서명 값을 고객의 인증서로 검증해 보고, 검증을 통과해야만 인증서 로그인 https 접속이 시작됩니다. 여기 참조

2. 거래 내역 전자서명은 무의미 합니다(인증서 로그인 https 세션을 채택할 경우)

인증서 로그인 단계에서 서버는 이처럼 고객의 전자서명을 확보합니다. 비인증 https 세션과는 달리, 인증서 로그인으로 개시된 https 세션 중에 공격자가 끼어드는 것은 현재 기술로는 불가능합니다(이론 없음). 따라서, 그 세션 중에 이루어지는 어떤 거래에 대하여 “또다시” 전자서명을 요구하는 것은 보안상 하등 의미가 없습니다. 인증서 로그인 https 접속에 성공하는 공격자는 서버가 수십번, 수백번 전자서명을 거듭 요구해도 다 해치울 수 있기 때문입니다. 인증서 로그인에 성공하지 못하는 자는 아예 그 거래에 끼어들 수도 없습니다.

“거래 내역”을 전자서명 해야만 부인방지 효과를 거둘 수 있다는 잘못된 견해가 한국에 널리 퍼지게 된 이유는, 지금까지 인증서 로그인 https 접속을 채택한 적이 없고, 그냥 http 접속으로 금융거래가 이루어져 왔기 때문입니다. 물론, 별도 플러그인으로 인증서 로그인을 하긴 했지만, 로그인만 통과하고 나면, 다시 단순 암호화 접속(플러그인으로 수행하는 비인증 SSL 암호화 교신)으로 거래가 이루어지므로, 해당 “거래 내역”에 대하여 전자서명을 반드시 받아야 하는 구조였습니다.

인증서 로그인 https 접속을 하고, 거래의 전 과정이 고객 인증 https 접속으로 이루어질 경우, 더 이상 개별 거래내역(송금 내역 등)에 대하여 또다시 전자서명을 요구할 아무런 보안 기술적 이유도, 논거도 없습니다.

3. 고객의 이용환경 지원 범위

인증서 로그인 https 세션은 거의 모든 기기, OS/Web-browser 가 이미 지원하고 있습니다. 고객이 별도 프로그램을 내려받아 설치할 필요도 없습니다. 반면에, 거래 내역 서명 기능은 어떤 웹브라우저도 지원하지 않고, 앞으로도 지원될 가능성이 희박합니다. 거래 내역 서명기능을 아예 웹브라우저에 포함시키자는 요청이 오래 전부터 거론 되긴 하였으나, 웹브라우저가 이미 제공하는 인증서 로그인 https 접속 기법에 익숙한 외국의 전문가들은, (로그인 때 이미 고객이 전자서명을 해보낸 상황을 전제하고 생각하므로) 거래 내역을 또다시 서명하게 했으면 좋겠다는 한국 전문가의 견해를 “무의미한 옥상옥”으로 여기는 것으로 보입니다. 이 문제는 더 이상 진전이 없습니다.

웹브라우저로 이루어지는 거래에서 거래 내역을 서명하려면, 반드시 별도의 플러그인/프로그램이 필요합니다. 플러그인은 원래 매우 비싼 해법이고, 이용자 지원 범위는 불가피하게 대폭 제한 됩니다. 반면에 인증서 로그인 https 접속으로 고객의 전자서명/부인방지 효과를 확보하는 해법은 거의 universal 한 지원이 가능하고, 서비스 제공자에게 플러그인 배포/유지/관리/고객 지원/업그레이드 부담은 전혀 없는 해법입니다.

보안 프로그램 판매를 원하는 보안업체에게는 별도 플러그인 해법이 단연 유리합니다. 끝없이 문제가 발생하고, 그 문제를 땜빵질해야 하는 수요도 끝없이 발생하며, 사태는 점점 꼬이고, 그 과정에서 겉으로는 죽는 소리를 하지만, 결국 비즈니스는 계속 유지될 수 있기 때문입니다. 어차피 자신의 위상을 “보안 노가다” 등 자조적 표현을 동원하여 규정하는 저급한 업체들은 이 수준의 소박한 사업에 만족하며 이 사태가 지속되기를 바라게 됩니다.

반면에 인증서 로그인 https 접속을 채용할 경우, 보안 프로그램이나 전자서명 플러그인 판매 가능성은 거의 완전히 사라집니다. 그 대신, 서버의 설계 자체를 보다 sophisticated된 형태로 해야 하고, load balancing proxy나 ssl 가속 proxy, DDoS 방어 서버 등을 세련된 방법으로 구사해야 하는 고난도 기술이 필요합니다. 이런 기술을 구비하지 못한 보안업체는 퇴출 위기에 직면하게 됩니다(단순 http 접속으로 모든 것을 해치울 경우, load balancing 등은 비교적 쉽습니다). 국내에서 그동안 이른바 “SSL 취약론“이 끈질지게 흘러나온 이유가 없지는 않습니다.

4. 인증서 저장 방법의 차이

현재와 같이 단순 폴더에 일반 파일 형태로 저장되는 인증서는 “해괴한 해법”이라고 밖에는 달리 할 말이 없습니다. 보안 상식을 벗어난 처사입니다. 웹브라우저에 저장되는 인증서는 공격자가 함부로 복사하기도 어렵고, 복사해 가도 사용이 매우 어렵도록 웹브라우저 설계 과정에서 여러 방어 대책이 마련되어 있습니다. 어떤 대책도 “완벽”하지는 않으나, 전세계의 전문가들에 의하여 투명하게 검증되는 방법이고, 현재로서는 가장 안전한 방법으로 저장되는 것입니다. 하드웨어 토큰에 저장되는 경우는 물론 더욱 안전합니다. 하드웨어 토큰에 저장될 경우에도, PC에서 구동하는 주요 웹브라우저는 별도의 프로그램 없이 인증서 로그인 https 접속을 수행할 수 있습니다.

반면에 한국 방식의 저장은 copy+paste 만으로 파일 자체는 당장 유출되고(OTL), 인증서 비밀번호 또한 국내 에서는 (아래에서 설명하듯이) “해괴한” 방법으로 운용되므로, 인증서 비밀번호 유출도 비교적 쉽습니다. 도저히 보안 상식으로는 설명이 불가능한 방식입니다.

5. 인증서 비밀번호 문제

인증서가 웹브라우저나 하드웨어 토큰에 저장될 경우에는 “인증서 비밀번호”라는 개념 자체가 아예 없습니다. 그대신, 웹브라우저 저장장치(MS CryptoAPI, NSS builtin object token 등)에 접근하는데 필요한 비밀번호를 입력하는 경우가 있고, 하드웨어 토큰에 접근하는데 필요한 비밀번호를 입력하게 됩니다.

그런데, 이런 비밀번호는 해당 machine 에서만 기능하는 것이므로, 아무리 유출되어 본들, 공격자는 전혀 사용할 수가 없습니다. 파이어폭스, 오페라 등 웹브라우저에서는 master password 라고 부르는 것인데, 이 비밀번호는 이용자가 자신의 컴퓨터에만 사용할 수 있도록 자신이 지정한 비밀번호 입니다. “인증서 비밀번호”가 아닙니다.

키보드보안 프로그램을 설치해야 한다고 “생 난리”를 치는 한국의 상황은 인증서를 해괴한 위치에 저장하고, “인증서 암호”라는 것을 괴상하게 운용하기 때문에 생겨나는 현상입니다.

“인증서 암호”라는 개념은 인증서를 “이동”할때(예를 들어, 집 컴퓨터의 웹브라우저에 저장된 인증서를 회사 컴퓨터 웹브라우저로 이동), 그 기간 동안 “일반” 파일 형태(*.p12 또는 *.pfx)로 인증서가 존재하는 위험한 상태가 생기는데, 이 기간 동안 그 파일을 암호화해서 보호하려는 목적일 뿐 입니다. 일단 웹브라우저의 보안장치(security device)에 가져오기(import)하고 나서는 인증서 암호라는 개념은 무의미 합니다. 즉, 고객이 온라인 상태에서 거래를 수행할 때(원격 공격 가능성은 이때 존재합니다)에는 인증서 암호라는 개념은 없습니다.

즉, 인증서를 실제로 사용하는 단계에서는 공격자가 가로채 가서 써먹을 수 있는 “인증서 암호”라는 것이 아에 없도록 설계되어 있는 것이 바로 PKI 기술의 본래의도 입니다.

한국의 상황은 한마디로 “엉망진창”으로 꼬여 있습니다.

앞으로 해결책은 공인인증서를 더 이상 일반 파일 형태로 폴더에 저장하는 괴상한 짓을 그만두고, 웹브라우저에 저장하거나, 하드웨어 토큰에 저장되도록 “발급”해 주는 것입니다.

괴상한 위치에 인증서를 저장해 놓고, 그 인증서를 불러오는데 필요한 인증 프로그램을 팔아서 영업하고, 고객이 거래때마다 ‘인증서 암호’라는 것을 매번 입력하게 만들어 놓고, 그것의 유출을 막겠다고 키보드보안 프로그램을 팔려는 황당하고 부끄러운 국내의 “보안 관행”은 없어져야 할 것입니다.

하나은행 방식과는 다릅니다. 아무런 앱도 설치할 필요가 없습니다. 위험/허술한 방식? 한번 읽어 보시고 판단하시죠.

• 윈도우가 설치된 PC에서 MS IE 웹브라우저로 금결원 인증센터에 접속하여, 인증서 “암호 변경” 부터 먼저 합니다. 이때까지 한번도 사용한 적이 없는 10자리 이상으로 된 것으로 정하십시오. 잠시 후 내보내기 할 때와 아이폰에 가져오기할 때 딱 1번씩만 사용하고 버리는 “일회용 암호”입니다. 외울 필요는 없고, 종이에 적어두세요.
• 암호변경이 되고 나면, 공인인증서 내보내기를 하여 *.p12 파일을 만듭니다. 내보내기도 위에 링크된 금결원 페이지에서 할 수 있습니다. 변경된 새 암호를 이때 한번 사용합니다.
• 이렇게 일회용 암호로 보호된 .p12 파일을 이메일 첨부파일로 자신에게 보냅니다.
• 공격자가 이미 자신의 이메일 계정 암호를 알고 있다고 가정해도 염려는 없습니다. p12 파일은 평소의 인증서 암호나 이메일 암호와도 다른, 내보내기 용 “일회용 암호”로 잠겨있습니다. 따라서 공격자가 이메일 계정을 액세스해서 인증서 p12 파일을 가져가 본들, 그것으로 무슨 짓을 할 수는 없습니다. 한번도 사용한 적이 없는, 외울 필요도 없이 긴 것으로 내보내기 암호를 정해야 하는 이유는 여기에 있습니다.
• 아이폰/아이팟터치로 자신의 메일을 열어, 첨부파일로 온 p12 인증서 파일을 가볍게 한번 “탭” 합니다.

이메일 첨부 파일로 전달된 인증서

나머지 과정은 아이폰의 안내에 따르면 됩니다. 인증서를 설치하겠는지를 묻는 창이 뜹니다. 설치(Install)을 선택합니다.

인증서 설치 여부를 묻는 창

그러면, 애플사는 여러분의 공인인증서를 발급한 금결원, 그리고 금결원의 상위 인증기관인 KISA를 전혀 믿지 않는다는 사실이 다음과 같이 드러납니다. 금결원과 KISA가 신뢰받지 못하는 인증기관이므로, 여러분의 인증서가 진본인지 여부를 애플은 검증할 수 없다는 메세지가 다음과 같이 뜹니다.

MS IE 만 믿고, 아무도 믿어주지 않는 한국의 공인인증서

어차피 이때까지 아무도 믿어주지 않는 “공인”인증서를 우리만 믿어 왔으니, 아무 생각말고 “지금설치(Install Now)”를 누릅니다. “우물안 개구리”가 아이폰 때문에 너른 세상으로 졸지에 떠밀려 나온 형국이니, 이 정도야 감수 해야 겠지요.

그러면 다음과 같이 인증서 백업 암호를 입력하라는 창이 나옵니다. 인증서 내보내기에 사용한 “일회용 암호”를 바로 여기에 입력합니다.

인증서 내보내기에 사용한 일회용 암호를 입력

암호를 입력하고 “다음”을 누르면 인증서 설치 완료! 이제 이 암호는 다시는 사용할 일이 없습니다. 금결원 인증센터에 접속하여 PC에서 사용할 인증서 암호를 자신이 기억할 수 있는 것으로 도로 바꿀 용도로 한번 더 사용하고 (잊어) 버리면 되겠습니다.

인증서가 설치되고 나면, 테스트 해 보셔야지요. 아이폰/아이팟 터치로 여기를 접속해 보시기 바랍니다. 인증서가 한장만 설치된 분은 아무런 안내창이나 인증서 선택창이 없이, 그대로 접속이 이루어집니다. 인증서가 설치되지 않은 분은 아예 접속할 수 없습니다.

두장 이상 인증서가 설치된 분은 접속에 사용할 인증서를 선택할 필요가 있다는 점이 다음과 같이 안내됩니다.

인증서 로그인이 필요하다는 안내

두개 이상의 인증서가 설치되어 있을 경우에만, 다음과 같은 인증서 선택창이 뜹니다. 궁금하시면 테스트 인증서를 하나 추가로 설치해 보시기 바랍니다. 아이폰으로 이 링크를 누르기만 하면 테스트 인증서 설치과정이 위와 똑 같은 방법으로 진행됩니다(인증서 암호는 “password”입니다, 따옴표 없이).

인증서 선택 창

공인인증서로 로그인한 https 접속이 이루어진 광경입니다. 주소창에 자물쇠 보이시지요?

인증서 로그인 https 세션: 현재 기술로는 가장 안전한 접속 방법입니다.

물론, 고객들에게 이렇게 하라고 “안내”만 하고 내팽겨치는 은행은 없을 것입니다. 모든 고객들이 안전하고, 쉽게 인증서를 스마트폰으로 이동하여 사용할 수 있는 솔루션을 만들어 제공할 것입니다. 오픈웹이 지적하고자 하는 점은 바로 이 솔루션은 매우 안전하고, 깔끔하게 pure web 기반으로 가능하다는 점입니다.

공인인증서를 사용해야 한다고 해서 반드시 무슨 프로그램을 별도로 내려받아 고객의 컴퓨터/스마트폰에 설치할 필요가 없습니다.

내 컴퓨터/스마트폰, 이제 좀 그만 건드리라 이 말씀입니다.