안전한 온라인 뱅킹을 위하여

2009.02.18 글쓴이 youknowit

전자금융 거래와 관련된 보안 대책은 근본적 반성이 필요하다. 소관 부처인 금융감독원은 이용자 개인들에게 이른바 ‘보안 프로그램’을 추가로 덕지덕지 설치하라고 강요하는 것에만 목을 메고 있다고 해도 과언은 아니다. 보안접속 프로그램, 키보드 해킹 방지 프로그램, 개인 방화벽 프로그램, 안티 바이러스 프로그램 등이 금감원 공무원들이 생각하는 이른바 ‘보안 프로그램’이다. 공무원들은 이런 프로그램을 많이 설치하면 전자금융거래가 더욱 안전해 질 것이라고 막연히 믿고 있는 것 같다. 딱하기 그지 없다.

3부로 나뉘어 연재될 이 글에서는 전자금융 거래 보안에 대한 금융감독원의 정책이 안고 있는 문제점을 진단하고 해법을 제시하고자 한다. 제1부는 보안접속 프로그램에 관한 것이고, 제2부는 키보드 해킹방지 프로그램, 제3부는 개인 방화벽 및 안티 바이러스 프로그램에 관한 것이다.

[제1부: 보안접속 프로그램]

보안접속(secure connection)은 고객과 웹서버 간의 교신 내용이 네트워크 상에 오갈때 악의적 공격자가 그 내용을 가로채 읽어보지 못하게 하는 기능을 수행한다. 예를 들어 로그인 아이디와 비밀번호가 고객과 웹서버 간에 오갈때 제3자가 그 내용을 엿보지 못하게 할 필요가 있음은 당연하다. 대부분의 시중 은행들은 별도의 암호화 플러그인을 사용하여 보안접속 기능을 구현하고 있다. 구체적인 방법은 교신채널 자체를 암호화하거나, 전송되는 메시지 내용을 암호화하는 두가지로 대별할 수 있다. 그러나, 컴퓨터 보안에 대한 올바른 기초지식이 있는 자라면 보안접속을 굳이 이렇게 별도의 플러그인으로 구현하는 것은 ‘해괴망측’하다고 밖에는 도저히 달리 설명할 수 없다.

웹브라우저에는 이미 보안접속 기능이 내장되어 있다. 그러나 2000년까지는 미국정부가 미국 내의 MS IE 웹브라우저는 128bit 수준의 보안접속을 허용했으나, 미국 외로 수출되는 MS IE 웹브라우저는 40bit 이상의 보안접속을 하지 못하도록 금지해 왔었다. 40bit 수준의 암호화는 1997년 경의 연산능력으로도 이미 3.5시간 만에 깨지는 무용지물이었다. 여기 참조. 바로 그렇기 때문에 국내의 보안업체들은 128bit 보안접속을 위한 별도 프로그램을 개발하는데 열을 올렸으며, 그렇게 개발된 보안접속 프로그램이 웹브라우저 플러그인(부가 프로그램)으로 배포되어 국내 온라인 뱅킹에 사용되기 시작한 것이다.

지금은 2009년이다. 한국 내에 사용되는 MS IE 조차도 이제는 128bit 보안접속 기능을 기본으로 장착하고 있다(2000.7.에 한국을 포함한 전세계에 배포된 MS IE 5.5부터는 128bit 보안접속 기능이 기본 장착되었으니, 지난 9년 가까이 이미 그랬던 셈이다) . 파이어폭스, 사파리, 오페라 등의 웹브라우저는 256bit 보안접속을 기본으로 채용하고 있다. 웹브라우저로 https://www.fortify.net/sslcheck.html 에 접속하면, 자신이 사용하는 웹브라우저가 어느 수준까지의 보안접속을 수행할 능력이 있는지를 당장 확인할 수 있다. MS IE나 구글 크롬 웹브라우저가 수행하는 보안접속(RC4 cipher를 이용한 128bit 암호화)이나 파이어폭스, 오페라가 수행하는 보안접속(AES cipher를 이용한 256bit 암호화)이 국내 보안접속 프로그램들이 제공하는 보안접속보다 허술하다거나, 해킹 위험에 더 노출되어 있다는 주장은 상식을 가진자라면 아무도 내세우지 않는다.

128bit 보안접속을 위하여 별도의 보안프로그램을 설치해야 된다는 주장은 90년대 후반에 개발한 한물 간 소프트웨어를 아무 기술지식도 없는 고객(웹사이트 발주자)이나 공무원들에게 2009년에 와서까지 마케팅 해보겠다는 파렴치한 상술일 뿐 아니라, 아래에 설명하는 바와 같이, 보안 프로그램이라는 미명하에 실은 엄청난 보안 위험을 국가적으로 초래하는 사기극에 가깝다.

국내의 보안 업체들은 128bit 보안접속 프로그램을 ActiveX 플러그인 형태로 배포하고 있다. 2000년 전까지는 외국의 보안 업체들도 미국 외의 고객들을 위하여 보안접속 프로그램 개발에 열중했고, 이들도 128bit 보안접속을 가능하게 하는 프로그램을 개발하였지만, ActiveX형태로 배포하기보다는, 이용자가 자발적, 주체적으로 내려받아 설치하면 아예 웹브라우저 자체가 128bit 보안접속을 수행하도록 하는 방식이 오히려 일반적이었다. MS사 역시도 미국 정부의 보안접속 제한 정책이 철폐되자 마자, 128bit 보안접속을 수행할 수 있는 보안접속 업데이트(Internet Explorer High Encryption Pack)를 전세계 이용자들에게 무료로 제공했으므로, 이 업데이트를 이용자가 내려받아 설치하면 MS IE 4.0으로도 128bit 보안접속을 할 수 있었다. 따라서 웹서핑 중에 이용자가 요청하지도 않았는데 웹서버가 난데 없이 제시하는 정체불명의 프로그램을 이용자가 자기 컴퓨터에 설치해야 하는 위험한 상황에 직면하지는 않게 된다.

그러나 한국의 보안업체들은 온 국민들이 무조건 자기(해당 보안업체)를 믿고 다음과 같은 보안 경고창이 나타나면, “반드시 OK”하도록 세뇌하는, 보안상 도저히 납득할 수 없는 전략을 선택하였다.

citibank_codesign

이 프로그램을 믿어도 좋을지를 이용자들이 도무지 어떻게 판단할 것인가? MS사가 친절하게 설명하는 “위험성”에 대한 안내 링크를 실제로 클릭하여 그 내용을 꼼꼼히 읽고 ActiveX의 위험성을 정확히 이해하는 이용자가 과연 얼마나 될까? 위험한지 여부를 판단하는 유일한 근거는 위 그림에서 MS사 스스로가 고백하듯이, 오직 게시자(이 프로그램을 코드 사인하여 배포하는 자)를 신뢰할 수 있는지 여부(게시자의 명칭) 외에는 없다. 이러한 보안 경고창이 떴을 때, “설치”를 클릭하기 전에, “Initech, Inc.” 등으로 표시되는 게시자가 도대체 누구인지, 믿을만 한지를 확인하려 노력하는 이용자가 과연 몇명이나 될까?

“뭘 그리 꼬치꼬치 따지냐?” “그냥 믿고 설치하면 되지”라고 말하는 자는 아예 보안을 논할 자격이 없다. 현재 우리 전자금융거래의 안전을 저해하는 가장 심각한 위험 요인은 웹서버가 내려 주는 ActiveX를 이용자들이 “그냥 믿고 OK”를 누르는 행태로부터 초래되기 때문이다.

아무려면, 믿을 만한 웹서버에 접속했는데, 그 웹서버가 설마 나쁜 프로그램을 이용자에게 배포하랴? 그러나, 문제는 이용자들이 웹서버를 믿고 민감한 정보를 내보내야 할 때 처음부터 ssl 접속이 아니라 비보안접속(http 접속)을 하도록 강요당한다는데 있다. 악의적 공격 사이트가 ‘믿을 만한 사이트’인 것처럼 위장하는 일은 고객이 http로 접속할 경우 비교할 수 없으리 만큼 훨씬 쉬워진다.

따라서 어떤 사이트에 http로(비보안) 접속한 다음, 그 사이트가 내려 주는 ActiveX플러그인을 “무조건 믿고” 설치해야만 비로소 구현되는 국내 업체의 ‘보안접속’은 구조적, 원천적으로 위험하다. 이 모든 위험을 도대체 무엇 때문에 전 국민이 감수하라는 것인지 도저히 상식으로는 납득할 수 없다. 보안 서버(ssl 서버)를 채용하기만 하면 당장에 구현될(그것도 지금 보다 훨씬 강력한 수준의) 보안접속을 마다하고, 기술적, 논리적으로 위험 천만한 별도 보안접속 ActiveX프로그램 방식이 2009년에까지 국내에서 판을 치는 이 상황을 금감원 공무원들이 방치한다는 것은 직무유기로 형사처벌을 당해 마땅한 수준이라고 생각한다. 더 이상 아무 소용도 없는 한물 간 보안접속 프로그램을 어떻게든 계속 팔아보겠다는 국내 보안 업체들의 파렴치함도 이제는 공식적으로 문제삼을 때가 되었다고 생각한다. 미국 외로 수출되는 MS IE 웹브라우저의 암호화 수준을 인위적으로 허술하게 유지하려던 미국 정부의 정책이 폐기된 2000이후에는, 128bit 보안 접속 프로그램을 팔아보겠다는 외국의 업체는 없다.

이쯤 오면, 컴퓨터를 좀 한다는 사람은 SEED 암호화 알고리즘이 어떻느니, 국정원이 SEED 알고리즘 사용을 사실상 강제한다느니 하는 낯선 말을 늘어놓으면서, 국내에서는 별도의 보안접속 프로그램 사용이 제도적으로 강제되므로, 개발자로서는 어쩔 수 없다는 변명을 하곤 한다. 다시는 이런 근거 없는 주장이 반복되지 않았으면 좋겠다. SEED 암호화 알고리즘은 1999년(미국이 수출용 MS IE 의 보안접속 기능 제약을 해제하기 직전)에 한국 정보보호진흥원 기술진이 개발한 128bit 블록 사이퍼 알고리즘이다. 그러나 SEED 알고리즘의 사용을 강제하는 규정은 어디에도 없다. SEED 알고리즘이 ‘언급’된 곳은 전자서명법 하위 규정 중 하나인 ‘전자서명인증체계 기술규격2.3’이다. 그러나 이 규정은 보안접속과는 아무런 관련도 없다. 인증서는 그에 상응하는 개인키가 있게 마련인데, 이 개인키 파일은 반드시 암호화해서 보관해야 한다. 그래야 다른 사람이 혹시 그 개인키 파일을 무단 입수하더라도 비밀번호를 모르면 함부로 전자서명을 할 수 없게 되므로 덜 위험해지는 것이다. 전자서명관련 규정에서 말하는 “암호 알고리즘”은 개인키 파일 보호를 위한 것일 뿐(기술 규격2.3은 SEED 또는 TDES를 사용해서 개인키 암호화를 하도록 규정하고 있다), 보안접속과는 전혀 상관이 없다는 점은 한국정보보호진흥원의 기술 책임자가 필자에게 직접 확인한 바이다. 국가정보원이 SEED사용을 강제할 이유도 없을 뿐 아니라, 국가정보원은 공공기관이 사용하는 보안 프로그램의 모듈에 대한 심의권한 만을 가지고 있을 뿐(전자정부법에 근거), 인터넷 뱅킹과 관련하여 국정원이 이래라 저래라 할 처지에 있는 것도 아니다. 법규정은 전혀 모르고, 보안 기술 마저도 잘 모르는 ‘얼치기 전문가’들이 지금까지 퍼뜨리고 다닌 황당무계한 ‘SEED-국정원’ 유언비어는 이제 좀 그만 틀었으면 한다.

적어도 보안접속은 더 이상 해괴 망측한 별도 프로그램 방식이 아니라, 보안 서버(ssl 서버)를 채용함으로써 안전하고 간편하게(별도 프로그램 설치 없이) 구현되어야 한다. 보안을 빙자하여 막대한 보안 위험을 그 동안 초래해 온 이른바 ‘보안접속용 별도 프로그램’은 당장 걷어내야 한다.

키보드 해킹 방지 프로그램 [제2편]
개인 방화벽, 안티 바이러스 프로그램 [제3편]
[결론 및 제안]

Categories: 인터넷 뱅킹, 전자정부, 정책제안 | 10 comments  오픈웹 구독 메일로 받기

2 Pingbacks/Trackbacks

  • http://lbjcom.net lbjcom

    좋은 글 잘 봤습니다. 대략적으로만 알고 있던 내용들이었는데 상세하게 잘 써주셨네요^^
    다음 글도 기대하고 있겠습니다.

    ps. 언제쯤 우리 나라는 정신을 차릴까요?ㅠ.

  • VongZa

    오랜만에 들어왔는데 마침 새 글이 올라와있네요.
    좋은 말씀 언제나 잘 보고 있습니다.
    저도 금융회사에서 일하고 있는데
    홈페이지 관련 부서에 우리회사 홈페이지에
    어느 브라우저에서도 접속이 가능하게 해달라고
    건의를 했더니 검토중이라는 애매한 답변만 하더라구요.
    어서 빨리 좀 바꾸었으면 좋겠는데…
    갈 길이 머네요. ^^;;;

  • 우분투

    체널->채널
    메세지->메시지
    http://krdic.naver.com/

  • 우분투

    운영체제나 브라우저와 상관없이 소리바다 홈페이지에서 1분간 미리 듣기가 되네요.
    http://www.soribada.com/

  • http://me2day.net/geekinside 박성철

    정말 금감원이 가장 큰 문제 같습니다.
    어쩌면 보안 업체와 커넥션이 있을 것 같기도 하고요.
    웃기는 건 요즘 금융권 차세대 사업의 요구사항에는 꼭 ‘웹 표준화’가 들어간다죠. 지키지도 않으면서… (사실 은행 입장에서 금감원의 지침을 따르려면 어쩔 수 없는…)

  • Pingback: 20071210 :: 정치적으로 보다 바람직한 보안 경고창 » Wireframe

  • 박영진

    금융 기관 보안이 영 의심스럽기는 했지만, 이 정도일줄은 몰랐습니다. IT강국이라는 말이 부끄럽네요… 보안에 대한 의식을 바꾸지 않는다면, 국민들이 큰 피해를 받을 수도 있겠습니다. 정부 관료들의 무능을 성토해야 할 때인가 봅니다.

  • http://openweb.or.kr youknowit

    우분투/ 소리바다, 플래시로 정말 깔끔하게 처리했군요. 우리 모두가 계속 노력하면 이렇게 근사한 기술들이 빛을 볼 기회가 생깁니다.

  • Pingback: 오픈웹 논란에 대한 단상 « Open Web

  • http://twitter.com/kimys0202 Kim Yoonsik

    일목요연하게 잘 설명되어 있는 글이네요. 잘 보고 갑니다~

«

»