약 3년 가까이 소요된 오픈웹 소송은 원고 패소로 결론이 났습니다.

이 소송은 인터넷 기반의 어떤 서비스를 제공하는 자를 상대로 해서, 이용자가 선택한 특정 이용환경에서도 서비스를 제공해 달라는 요구를 한 것입니다. 법원은 서비스 제공자에게 그러한 “법률적” 의무를 지우는 것은 적절하지 않다고 판단하였습니다.

법원의 이러한 판단은 인터넷을 기반으로 이루어지는 다양한 서비스의 기술적 특성을 고려해 볼때, 법 제도와 법원의 판결 및 행정권력을 동원해서 이래라, 저래라 하는 것은 현명하지 않다는 고려가 깔려있는 것이라고 평가합니다. 비록 현재는 어떤 이유에서건 공인인증서비스가 MS IE 에서만 제공되고 있지만, 그것도 업계의 자율적 판단에 맡겨두는 것이 옳고, 법원이나 행정권력이 개입해서 이래라 저래라 하는 것은 기술의 특성상 시대착오적인 오류만을 남길 위험이 더 크다는 예측과 우려가 작용한 것이라고 이해할 수 있습니다.

공인인증기관 스스로의 자유로운 사업판단으로 서비스 제공여부를 자율적으로 결정하면 된다는 피고의 주장을 받아들인 이번 대법원 판결이 앞으로 인터넷 기반의 여러 다양한 서비스 제공자들의 운신의 폭을 더욱 넓게 보장하고, 더 자유롭고 다양한 서비스의 등장을 촉진하는 계기가 될 수 있도록 모두가 노력하면 될 것입니다.

예를 들어, 쇼핑몰이나 금융기관의 경우에도, 각 서비스 제공자가 스스로의 자유로운 사업 판단으로 현재 전 세계적으로 통용되는 수준의 보안 조치를 취하면서 서비스를 제공하면 될 것입니다. 쓸데 없이 행정권력이나 법원이 개입해서 공인인증서를 사용하라느니, 키보드 보안 플러그인을 반드시 사용하라느니 강제하는 것은 적절하지 않습니다.

특히 공인인증서의 경우에는 공인인증기관이 그 사용에 필요한 서비스와 소프트웨어를 제공하는 환경에서는 그렇게 제공된 소프트웨어를 은행이나 쇼핑몰이 사용하면 될 것입니다. 공인인증기관이 공인인증서 사용을 지원하지 않는 환경에서는 공인인증서 없이 금융거래를 하면 되는 것입니다.

공인인증 서비스를 제공해야 할 “법률상 의무”를 지고 있는 공인인증기관(이점은 아무 논란이 없습니다)도 자유로운 사업판단으로 공인인증서비스를 제공할지 말지를 스스로 판단할 수 있다고 대법원이 판결하였으므로, 공인인증기관도 아닌 은행이나 쇼핑몰이 공인인증서 이용에 필요한 소프트웨어를 스스로 만들어야 할 “의무”가 있을 리는 없습니다.

따라서, 쇼핑몰이건, 은행이건 새로운 서비스를 보다 광범한 이용환경(예를 들어 아이폰, 아이팟, 스마트 폰 등)에서 국제 수준으로 안전하게 제공하고자 하는 곳이 있으면, 이제 아무런 부담없이 자율적이고, 국제적인 기술 수준에 맟추어 자신의 서비스를 설계하고, 보다 광범한 고객층을 상대로 국제적으로 사업을 펼치면 되는 것입니다. (MS IE 사용자에게는 지난 10년 간 해왔던 수준의 서비스를 계속 제공하면 되지 않겠습니까?)

법원이나, 행정 관료가 “법 규정”이나 “시행 세칙” 조문을 내세워 이래라 저래라 참견하고, 딴지를 거는 일은 이번 대법원 판결로 확정적으로 거부된 것이라고 생각합니다.

대법원 판결문은 http://openweb.or.kr/uploads/openweb_judgment.pdf 에 있습니다.

금융결제원 담당자 및 그 소송대리인들께 축하와 치하의 말씀을 드립니다.

항소심 판결은 http://lawlec.korea.ac.kr/up/appellate_judgment_kim.pdf 에 있습니다.
텍스트 버전은: http://openweb.or.kr/uploads/appellate_judgment_kim-utf8.txt (snowall 님께서 수고해 주셨습니다. 고맙습니다. http://snowall.tistory.com/1359 )

5월22일 제출된 상고이유서는 http://lawlec.korea.ac.kr/up/2nd_appeal_kim_brief_pub.pdf 에 있습니다.
텍스트 버전은 여기: http://openweb.or.kr/uploads/2nd_appeal_kim_brief.txt

상고이유서는 5월25일에 금융결제원에 송달되었으므로, 곧 금융결제원의 답변서가 제출될 것입니다. 답변서를 받는 대로 게시하겠습니다.

이것도 예전에 제 블로그에 적어놨던 글인데, 더 많은 분들과 내용을 공유하고 싶어 오픈웹에다가도 올려봅니다.

–
나는 오늘도 인터넷 뱅킹을 위해 모 은행의 홈페이지로 접속했고, 플러그인을 설치해야한다는 페이지를 5분동안 보고 있어야 했다. ‘왜 안넘어가는거야!’ 라고 짜증을 내며 브라우저를 보니 firefox다. 비굴하게 32bit 버젼의 인터넷 익스플로러를 사용해서 접속하니 나도 모르게 실행되는 백신과 키보드 보안 프로그램 그리고 XecureWeb…

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

도대체 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를 작성할 수도 있다.

예전에 제 블로그에 올렸던 글인데, 더 많은 사람들과 공유하기 위해 오픈웹에도 전문을 올려봅니다.

좋은 내용의 글을 발견해서 살짜쿵 번역을 해봤습니다. ‘국내 CA 시스템 = 공인인증 시스템’ 이라고 이해하시면 되겠습니다. 약간의 의역이 있고, 오역도 있을 수 있습니다. -_-a

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

원문: 여기를 클릭
–
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 또는 CRL을 이용하여 확인하는 경우도 있습니다.) 그런 다음 웹서버에서는 요청된 작업이 실행된 후 그 결과를 사용자에게 http 채널로 보내줍니다. 이 때 일부 은행 사이트에선 결과를 암호화해서 보내기도 하는데, 이경우, 사용자는 서버로부터 전달받은 암호화된 메시지를 ActiveX와 Javascript를 통해 복호화해야 합니다.

대부분의 브라우져는 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] 홈브류란 단어는 집에서 만드는 무언가를 얘기할 때 많이 쓰던데 뭐라고 표현해야할지 모르겠어서 발음대로 표기했습니다. 홈브류 맥주, 홈브류 와인 이런 식으로 쓰는 말이에요.