읽다보면 참 부끄러운 부분이 많아요.

원문: http://web.archive.org/we...ean-home-brew-on-the-web/

–
Vladimir씨는 SEED에 관련된 기술적인 문제를 얘기하기 위해 한국의 인터넷 뱅킹을 이용해본 경험을 이야기 했습니다. 그가 한국 사이트에서 겪었던 문제들 덕분에 그 문제에 대해 기술적인 부분을 설명할 기회가 왔네요. (이 글을 읽기 전에 Vladimir씨가 쓴 “It’s gone to SEED”를 먼저 읽으시기 바랍니다.)

1997년에 SEED가 처음 나왔을 당시엔 암호화를 위해선 ActiveX나 NSPlugin(브라우져 전쟁 이후에 사라졌음)를 이용할 수 밖엔 없었습니다. 이 플러그인들은 국내 전용의 CA들로부터 개인 인증서를 발행하고, 관리하는 역할과 돈을 보낼 때 계좌번호 같은 “중요한 텍스트” 들에 “전자 서명을 더하는” 역할을 담당했습니다. INISafeWeb 또한 이런 플러그인들 중 하나입니다. (한국에는 금융/전자상거래 및 전자 정부 사용 등의 서비스를 위한 국내 전용 CA들이 8개 정도 있습니다. 이런 서비스를 이용하기 위해서는 같은 기능을 하는 ActiveX를 최소 3개 이상 설치해야만 합니다. 참 웃긴 일이죠.)

이제부터 ActiveX를 사용한 거래 과정을 명확하게 설명해볼까 합니다. 만약 누군가 보안된 거래를 하려한다면 그 사람은 필요한 정보를 HTML Form에 채워넣습니다. Submit에 의해 호출된 Javascript는 이 정보를 암호화를 담당하는 ActiveX 컨트롤에 전해주게 됩니다. 이 컨트롤은 이 값들을 암호화하고 사용자의 공개키를 이용하여 전자 서명을 추가합니다. ActiveX에 의해 암호화된 메시지는 HTML Form으로 다시 전해지고, 마지막으로 form.submit()이 실행됩니다. 웹서버는 사용자의 인증서로 만들어진 데이터를 OCSP 같은 CA를 통해 복호/검증하게 됩니다. 그런 다음 웹서버에서는 요청된 작업이 실행된 후 그 결과를 브라우져로 보내줍니다. 이 때 일부 은행 사이트에선 결과를 ActiveX와 Javascript를 통해 복호해야 하는 암호 메시지로 보내줍니다.

이 과정은 사실 SSL을 이용할 때와 거의 동일합니다. 대부분의 브라우져는 Mr Vladimir씨가 보았던 인터페이스와 비슷한 인증서 관리자를 가지고 있는데 한국에서는 왜 브라우져의 기본 함수를 사용하지 않는걸까요? 그 이유는 SEED라는 암호화 알고리즘과 표준화 되지 않은 브라우져의 전자 서명 기능입니다. 10년 전에 이미 생각되었던crypto.signText()같은 형태인데, 어쨌든 암호화를 담당하는 ActiveX들이 이런 함수를 가지고 있습니다.

마지막으로, 다른 ActiveX 컨트롤들에 대해 설명해보겠습니다. 예전에 키로깅이나 개인 인증서에 대한 해킹으로 인한 금융 사고들이 있었던 적이 있습니다. 이건 사실 한국 사용자들의 무분별한 ActiveX설치로 인해 발생한 문제였습니다. (대부분의 사람들이 IE에서 ActiveX 설치와 관련된 보안 경고를 보여줬을 때 “Yes”를 클릭하도록 학습되어 있습니다. 왜냐구요? 대부분의 공용 서비스에서 ActiveX를 사용하거든요. 그러다보니 spyware나 malware에 속수무책일 수 밖에 없습니다. 보안과 관련해서는 악순환일 수 밖에 없습니다.) 그렇기 때문에 대부분의 은행에서는 강제로 키로깅(“Softcamp”)을 막고, 파이어월을 제공하고, ActiveX들에 대한 백신(“하우리”)을 제공하기 시작했습니다. InsisWeb은 신한은행에서만 보험을 위해 사용하는 ActiveX입니다. 이런 툴들은 여러 회사의 제품이 나와있으므로, 암호화를 위한 ActiveX 때와 마찬가지로 설치된 ActiveX는 계속해서 늘어납니다. 아마 대부분의 한국인들은 공용 서비스를 이용하기 위해 10개 이상의 ActiveX를 사용하고 있을거에요.

문제는 ActiveX가 사이트와 매우 긴밀하게 연결되어 있기 때문에 사용자들이 이 ActiveX를 선택할 권리가 없다는 것입니다. 그게 끝이 아닙니다. 대부분의 전자 정부 사이트는 모든 인쇄 서비스에 DRM을 걸기 위해 ActiveX를 사용합니다. 신용카드 거래를 위한 ActiveX 컨트롤들도 여러가지입니다. 한국에서는 심지어 Visa3D마저도 ActiveX로 구동됩니다. (정부는 국내 CA시스템들에 30만원이 넘는 거래에 대해 국내 CA System을 사용하도록 하는 가이드라인을 제공하고 있습니다. 온라인 쇼핑몰에서 뭔가를 사고 싶다면, 위에서 얘기한 것들을 설치해야합니다.) 전자 상거래를 하고 싶다면…? 또 다른 ActiveX가 필요하겠죠.

상황은 매우 심각합니다. 윈도우 98에 대한 지원이 얼마 남지 않았꼬, 곧 XP SP2에 대한 지원도 끝날거라는 경고가 있었습니다. 하지만 한국 정부는 이런 사실을 무시하고 있고, 대부분의 소프트웨어 회사는 자신들의 밥그릇을 지키려고 낑낑데고 있을 뿐입니다. 현재 한국에서의 상황은 SEED만의 문제가 아닙니다. 내부 해커들의 공격에 시달리는 윈도우와 인터넷 익스플로러에 맞춰진 국내 인트라넷 시스템이 되어버렸습니다. 한국의 홈브류[1] 인터넷이죠.

–
[1] 홈브류란 단어는 집에서 만드는 무언가를 얘기할 때 많이 쓰던데 뭐라고 표현해야할지 모르겠어서 발음대로 표기했습니다. 홈브류 맥주, 홈브류 와인 이런 식으로 쓰는 말이에요.

Related Posts

• 1/28/2009 -- 인터넷 뱅킹과 크로스 브라우징 (2)
• 10/25/2007 -- 오픈웹과 관련해서… (4)
• 9/15/2007 -- 64bit Windows Vista 와 신한은행… (13)
• 2/7/2010 -- 인터넷 결제 시스템을 언제까지 익스플로러에 가둬놓을 셈인가? (3)
• 4/6/2009 -- 오픈웹 관련해서 시끄러운 하루하루… (2)

이 은행에 있던 돈을 다른 은행에 있는 계좌로 이체를 시킨 뒤 잔고가 얼마인지 확인하기 위해 또 다른 은행사 홈페이지로 접속을 했고, 또 다른 프로그램들이 실행되기 시작했다.

도대체 XecureWeb, INISafeWeb등이 뭐하는 프로그램이길래 설치를 강요받아야 하고, 또 무슨 근거로 신뢰를 강요받아야 하는걸까?

XecureWeb / INISafeWeb 도대체 얘네 뭐하는 애들이야?

크게 인터넷 뱅킹에서 필요한 기능은 두 가지 이다. 인터넷 뱅킹을 하는 동안 오가는 데이터를 중간에서 가로챈다고 하더라도 그 내용을 알아 볼 수 없게 하기 위해 보안 채널을 구성하는 것이 그 첫번째이고, 거래(계좌 이체 등)를 한 사람이 본인이라는 사실을 증명하는 것이 그 두번째이다.

위에 열거한 프로그램들이 위에서 얘기한 두 가지 기능을 제공하기 위한 플러그인이라 할 수 있지만 불행하게도 Microsoft Windows용 플러그인만 제공되고 있다.[1] 덕분에 Mac OS X 이나 Linux 등에서는 인터넷 뱅킹을 이용하는 게 쉽지 않고, 일부 플러그인의 경우 윈도우용 firefox를 위한 플러그인도 제공하고 있지만 플러그인의 버젼을 체크하는 javascript 문제로 firefox에서는 동작하지 않는 경우가 태반이라 (BC카드 홈페이지가 대표적 사례) 인터넷 뱅킹은 윈도우용 인터넷 익스플로러 전용 서비스라고 해도 과언이 아닌 것 같다.

그럼 대안은 없는건가?

우선 보안 채널을 형성하는 것과 관련해서는 http over ssl(이하 https)이라는 훌륭한 대안이 있다. 위에서 얘기한 플러그인들의 경우 브라우저나 웹서버에서 기본으로 제공하는 방법이 아닌 자신들 고유의 방법으로 보안 채널을 형성해야 하기 때문에 개발이 복잡해질 수 밖에 없다.

하지만 https 는 대부분의 웹서버와 브라우저에 구현되어 있기 때문에 프로토콜을 https로 명시해주면 끝이므로 개발 비용 및 추가 비용이 발생하지 않는다. 이미 널리 사용되고 있는 방법이므로 Microsoft Windows, Mac OS X, Linux, Firefox, Internet explorer, Opera, lynx, links, w3m 등 어떤 OS, 어떤 브라우저에서도 이용에 제한을 받지 않는다. 심지어는 w3m 같은 텍스트 브라우저마저도 https를 지원한다.

거래를 한 사람이 나라는 사실을 증명하는 방법으로는 전자 서명이 있고, 이는 페이지의 해쉬 값을 내 공인인증서로 암호화 한 내용[2]을 덧붙이는 식으로 구현된다.

이를 위해 필요한 기능은 공인인증서(자신의 사설인증서)로 페이지의 해쉬 값을 암호화 하는 기능이며, 기본적으로 브라우저에서 제공되는 기능은 아니기 때문에 플러그인이 필요할 수 밖에 없다. 최근 크로스 브라우징에 대한 흥보의 효과인지 얼마 전 이니시스에서는 플래쉬 기반의 공인인증 시스템을 발표했지만 아쉽게도 아직까지 이 서비스는 전자 결제 대행에서만 이용이 가능 한 것으로 보인다. (오해가 있을 수 있을 것 같은데, INISafeWeb은 이니시스가 아닌 이니테크의 제품이다.)

하지만 그렇다 하더라도 같은 기능을 위해 각 사이트마다 다른 플러그인을 설치하도록 하는 것은 좋은 방법이라 할 수 없을 것 같다. 더 좋은 해결책이라면 공인인증을 위한 MIMETYPE을 표준화하고 이 MIMETYPE에 대한 처리를 담당하는 플러그인의 API, 즉 공인인증 API를 표준화 하여 이 API를 제대로 구현하고만 있다면 어떤 구현물을 사용하던 서로 호환이 가능하도록 만드는 것이라고 생각한다.

공인인증에 대한 표준화가 이루어진다면 하나의 공인인증 플러그인만으로도 모든 은행의 인터넷 뱅킹 서비스를 자유롭게 이용할 수 있게 될테고, 공인인증 플러그인이 제공되지 않는 브라우저라면 사용자가 스스로 플러그인을 제작해서 사용[3]하는 것도 가능해질 것이다.

마치며

웹은 특정 OS, 특정 브라우저에 제한되어서는 안된다고 생각한다. 암호화 채널을 https 로 바꾸는 것 만으로도 내 통장 거래 내역을 어떤 OS, 어떤 브라우져에서든지 간단히 확인할 수 있게 될 것이다. 비록 반쪽짜리이지만 이 정도만으로도 불편의 반 이상은 해결될 것이라 생각한다. 적용을 위해 약간의 노력이 필요하겠지만 이후 유지 보수의 편리함 등을 생각하면 이 노력은 충분한 의미가 있을 거라고 생각한다. (플러그인에 대한 라이센스 따위는 더 이상 필요 없어진다. 물론 XecureWeb 이라거나 INISafeWeb 등 현 기득권 업체들이 이 시장을 놓치려 하지 않을 것이므로 이 문제는 정치적으로 해결해야할 것이다.)

게다가 공인인증 API 를 표준화 하게 되면 나머지 반쪽의 문제도 해결될 것이다. 많은 것을 바라는 것은 아니다. 단지 자신이 좋아하는 운영체제, 자신이 좋아하는 브라우저를 사용하면서도 차별을 받지 않을 수 있길 바랄 뿐…

[1] XecureWeb의 경우 MS Windows / Mac OS X / Linux 용 플러그인을 모두 제공한다.

[2] 이를 이해하기 위해선 우선 공개키 / 비밀키 알고리즘에 대해 알아야 한다. 간단하게만 얘기하면 어떤 값을 공개키로 암호화 한 것은 비밀키로 복호화 할 수 있고, 어떤 값을 비밀키로 암호화 한 것은 공개키로 복호화가 가능하다.

비밀키는 나만 가질 수 있으므로 공개된 키로 암호화되어 전송된 내용은 나만이 해석할 수 있게 된다. 그렇기 때문에 보안 채널을 구성할 땐 공개키를 이용해서 암호화 하는 방식을 사용한다. (상대방에게 데이터를 전송할 땐 상대방의 공개키를 이용해서 암호화 한 뒤 보내고, 누군가 내게 데이터를 보낼 땐 내 공개키를 이용해서 암호화 한 뒤 보내주게 된다.)

반대로 내 비밀키로 암호화된 내용은 누구나 공개키로 풀어볼 수 있으므로 데이타를 보낼 때 데이터의 뒤에 그 데이타를 내 비밀키로 암호화된 내용을 덧붙인다면 이게 내가 보낸 데이타라는 것을 증명할 수 있게 된다. 실제로는 데이타 자체를 암호화 해서 보내기 보다는 데이타의 해쉬 값을 비밀키로 암호화 한 뒤 원래의 데이타 뒤에 이 값을 붙여서 보내게 된다. 이를 이용하는 애플리케이션으로는 enigmail 등이 있다.

[3] RSS에 비유를 해보자. RSS는 표준화가 되어있기 때문에 RSS feed를 관리하기 위해 특정 애플리케이션을 사용해야할 필요는 없다. 만약 자신이 사용하는 OS에 RSS Reader가 존재하지 않는다면 표준을 참고해서 직접 Reader를 작성할 수도 있다.

Related Posts

• 1/28/2009 -- 번역: 한국의 홈브류 인터넷 (0)
• 10/25/2007 -- 오픈웹과 관련해서… (4)
• 9/15/2007 -- 64bit Windows Vista 와 신한은행… (13)
• 4/6/2009 -- 오픈웹 관련해서 시끄러운 하루하루… (2)
• 2/7/2010 -- 인터넷 결제 시스템을 언제까지 익스플로러에 가둬놓을 셈인가? (3)