예전에 제 블로그에 올렸던 글인데, 더 많은 사람들과 공유하기 위해 오픈웹에도 전문을 올려봅니다.
좋은 내용의 글을 발견해서 살짜쿵 번역을 해봤습니다. ‘국내 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] 홈브류란 단어는 집에서 만드는 무언가를 얘기할 때 많이 쓰던데 뭐라고 표현해야할지 모르겠어서 발음대로 표기했습니다. 홈브류 맥주, 홈브류 와인 이런 식으로 쓰는 말이에요.