한국마이크로소프트 김국현 부장의 공인인증체제, 우리에게 임박한 미래로부터의 리스크라는 글을 풀어서 써봤다. 내용이나 취지에는 십분 공감하는데, 다시 읽어보니 이거 앞뒤 문장의 뜻을 잇는 것도 벅차다. 대강 읽고 대강대강 납득해버린 내 머리에 이럴때만 경의를 표하고 싶다 -_-;;
아 물론 남의 글을 멋대로 손대면 안된다는 것은 잘 알고 있지만.. 원 글이 좀 해도해도 너무하더라고. 이런 글은 한명이라도 더 많이 읽혀야 하지 않겠어?
아 물론 남의 글을 멋대로 손대면 안된다는 것은 잘 알고 있지만.. 원 글이 좀 해도해도 너무하더라고. 이런 글은 한명이라도 더 많이 읽혀야 하지 않겠어?
김국현(IT평론가)
웹에서의 금융결제 및 공인인증체제의 잠재적인 문제점, 또는 당면한 문제점과 그 개혁안에 대해서는 이미 많은 경로와 기회를 통해 이야기해 왔다. 그렇지만 2008년 여름 현재 아무 것도 바뀌지 않았다.
아마 어떠한 변화가 닥쳐 와도 현재 상태의 유지를 위한 범국가적인 기술 조정(tweaking)이 시도될 것이다. 체제의 관성이란 그런 것이다.
지금까지 금융권과 공공 분야 IT 인사들이 하나 같이 귀띔해준 것은, "보안에 관해서는 이야기를 꺼내지 말고 있는 그대로 받아 들이는 것이 상책"이라는 것이었다. 그도 그럴 것이 한 두사람이, 그리고 한 두개의 프로젝트가 바꿀 수 있는 규모란 뻔하기 때문이다. 괜히 나서서 입바른 소리했다가 통째로 책임지느니 그냥 묻어 가는 편이 속 편하다고 느끼기 마련이다.
게다가 상대는 법과 제도다. 기술 독과점 체제에서는 대형 사고가 터지지 않는다면 복지부동이 답이다. 합리적인 사정이다. 그러나 늘 그렇듯이 사회적 비용이란 뚜렷이 문제가 되지 않는 것처럼 보이던 것들이 하나씩 쌓이면서 발생한다.
현 체제의 근본적인 문제는 원칙도 없고 질서도 없으며 제멋대로인 체제가 국제적인 비준도 얻지 못한 채, 인터넷과 웹이라는 전세계적인 공간에 함부로 구조적 확장을 감행하여 스스로 필수 요소가 되려고 하는 것이다.
단기적인 해결책으로 금융이나 공공기관 사이트의 "불필요한" 추가요소들을 Java나 Silverlight 등의 비교적 플랫폼 독립적인 기술로 재개발하여 빼내면 되겠다고 생각할 수도 있지만, 이는 해법이 아닌 또 다른 미봉책일 뿐이다. 다른 나라는 굳이 하지 않는 일을 우리가 특별히 해야만 하는 이유가 있지 않다면 말이다. 정말 공인인증서란 것이 필요했었는지 스스로 회의를 품어보는 것이 더 본질적인 해법이다.
금융기관과 공공기관 웹 사이트를 실제로 통제하고 있는 국내의 공인 인증 체제는 기술적으로 반드시 필요해서 만들어진 것은 아니다. 다만 최근 몇 년동안 복잡하게 얽힌 상황이 우연히 정책으로 굳어진 것일 뿐이다. 그런데 왜 어째서 모두 이를 받아들이고 존속시키고 있는 것일까?
현재의 공인인증체제가 수행하고 있다고 보이는 일은 크게 두가지다.
1) '독자적인' 통신 암호화를 위한 인증서(비밀키) 기능
2) 거래 증빙 및 위조 방지, 부인 방지를 위한 전자서명 기능
수 차례 강조했듯이 첫 번째는 브라우저의 기본 기능으로 갈음할 수 있다. 오히려 현 체제보다 훨씬 많은 사람들이 훨씬 많은 시간을 들여 개발하였고 전세계적으로 검증되고 있는 제품이 바로 브라우저의 보안기능이다.
두 번째 사항은 금융거래 또는 공공기관 민원 제출시 해당 기관에 인증서를 제출하는 기능이다. 이는 현존하는 브라우저만으로는 불가능한데, 이것이 브라우저 내장 기능에 들어가 있지 않은 이유는 이렇게 사용자에게 불리한 일을 강요하는 국가가 대한민국 이외에는 없기 때문이다.
쉽게 말해서 문제가 생겼을 때 "내가 틀림 없이 이 거래를 했음"을 내가 해당 기관에 자진 신고하는 일인데, 이 얼개는 결코 '나'를 위한 것이 아니라 '시스템에는 책임이 없음'을 확실히 하기 위한 것일 뿐이다. 온라인 거래마다 '나'의 존재를 저당 잡히게 하는 의아한 제도인데, 덕분에 30만원짜리 쇼핑을 할 때마다 인감도장을 찍어야 한다는 넌센스가 그대로 남아있는 셈이다.
또한 이 제도가 반드시 존재해야 하는가에 대한 의문뿐만 아니라, 적용 효과에 있어서도 의문이 끊이지 않는다. 우리가 흔히 생각하고 있는 것과 달리 이 공인인증서는 그 자체로 실질 경제 주체인 '오프라인에서의 나'와 '온라인의 나' 사이를 직접 이어주지는 않아서, 비록 초기 발급 시에는 대면 검사를 필요로 한다고 하더라도, 발급 후에는 어떠한 현실 주체의 개입도 없이 사용되고 있다. 심지어 인증서 분실시의 재발급 절차는 굳이 본인이 아니더라도 계좌번호와 주민번호와 보안카드와 은행사이트에 등록된 ID만 있으면 온라인으로도 바로 신청이 가능하다.
그렇다면 그냥 이러한 정보들의 조합으로 인증해 주면 되는 것을 공인인증서라는 파일을 별도 생성하고 이를 마치 대단한 정보인양 우리에게 맡겨 놓는다. 사실 우리는 이미 같은 목적으로 '주민등록번호'라는 것을 지문날인까지 하며 부여 받은 바 있다.
점입가경인 것은 이렇게 쉽게 재발행된 인증서로 관공서 사이트에 갔더니 비밀번호는 커녕 주민번호만 넣으면 로그인과 계정 연결이 가능했다는 것이다. 일반인에게는 귀찮고 복잡한 미로를 만들고 그 곳이 안전하다고 착각하게끔 한다. 우리는 공인인증이라는 복잡 다단한 퍼즐 게임을 해왔음에 불과하다.
공인인증서가 무의미하고 또 사용자에게 불리함은 이렇듯 간단한 체험만으로 증명이 가능하다. 한국의 공인인증서는 이미 그 자체로도 충분한 브라우저와 운영체제(OS)의 보안 체계를 대체하려는 무모한 시도일 뿐이다. 이것은 보안을 강화하지도 않을 뿐만 아니라, 위와 같은 허점 때문에 현실의 나를 공히 대변하지도 못한다.
여기에 사용자의 온라인에서 행하는 모든 행위마다 그 사람이 "실제로" 한 거래라고 자동으로 추정하는 일은 기관의 편의를 위한 것이지 사용자는 아무런 혜택도 받지 못한다. 사용자가 이 체제로부터 얻는 것은 귀찮음이고 잃는 것은 시민으로서의 자유의지다. ‘공인’된 인감 도장을 모든 거래에 한 번씩 찍게 하는 기록형 통제 사회. 이 체제에 의미가 있다면 이러한 상징뿐이다.
(주: 법률용어로 '추정'은 확실하지 않은 사실을 그 반대 증거가 제시될 때까지 진실한 것으로 인정하여 법적 효과를 발생시키는 일)
우리에게 인증서와 같은 별도 서류를 소지하게 하는 이유는 이중요소인증(two factor authentication)에 대한 기대일 것이다.
이중요소인증의 기본은 '나만이 알고 있는 것', '나만이 갖고 있는 것' '나 자신' 중에서 둘 이상의 조합으로 인증을 강화하는 일이건만, 공인인증체제는 '나만이 알고 있는 것' 으로 '나만이 갖고 있는 것'을 온라인으로 만들어 낼 수 있게 하고, 그대로 인증을 통과하게 하는 모순을 지니고 있는 셈이다.
(주: 즉 A와 B의 조합이 아니라 A로 A'를 만들어서는 그것을 B로 삼는다는 말이다)
공인인증체제에 모순이 있다면 그 대안은 무엇일까? 원점으로 돌아가 이 체제가 해결하려 했던, 그럼에도 불구하고 해결하지 못한 맹점은 무엇이고, 그에 대한 대안이란 무엇인지 돌아볼 필요가 있다.
1) 통신 암호화를 위한 인증서(비밀키) 기능
현재 3대 브라우저(주: IE, Firefox, Opera 또는 Safari)의 자체 기능만으로 충분하다. 특히 이 기능을 '체험의 확장'을 위해 마련된 기술인 ActiveX로 구현하는 것은 무모한 일이다. ActiveX 기술 자체는 Win32라는 윈도우 프로그래밍 모델에 해당하므로 성숙된 기술이지만, 현재 그 주 용도와 사용처를 보면 플래시, 자바 애플릿, 실버라이트와 같은 '체험형' 런타임이 주가 된다.
(주: 더 아름답고 쓰기 편한 사용자 체험 (UX) 또는 사용자 인터페이스(UI)를 만들기 위해 쓰인다는 것)
물론 이것은 여전히 요긴한 기능이므로 Siebel처럼 기업 업무용으로도 유용하게 쓰일 것이다. 문제는 현재 ActiveX 컨트롤이 쓰이는 것을 보면이 문제다.
- 크로스 플랫폼 런타임도 아니고,
- 사용자 체험을 위한 공통 모듈도 아니면서,
- 단발적이고 즉흥적인데다가
- 원래 의도했던 목적이 아닌 보안과 같은 '구조적' 기능 확장에 이 기술이 남용되고,
- 그것도 사실상 바이러스나 악성 프로그램과 크게 다를 바 없는 방식으로 오용되고 있었다는 점
(주: 크로스 플랫폼이란, 한번 만들어 놓으면 윈도우에서도 맥에서도 리눅스에서도 돌아간다는 것임. '런타임'은 다른 프로그램이 돌아가도록 보조한다는 것. 즉 크로스 플랫폼 런타임을 아주 쉽게 설명하라면 '플래시' ㄳ)
그리고 대부분의 기능은 그 하부 구조에 더 잘 구현되어 있는 것의 재탕(reinventing the wheel)일 뿐이다. 인증 체제 및 결제 모듈은 물론 키보드 보안 모듈이나 은행에서 추가로 설치되는 파이어월 등 주변부 솔루션들도 다 이 부류에 해당된다. 해외의 예를 보더라도 이러한 방식으로 추가 설치를 강제하는 일은 매우 이례적이고 사용자에게 실례가 되는 일이기에 시행되지 않고 있다.
(주: 수레바퀴를 다시 발명하는 것처럼 쓸모없는 짓)
2) 거래 증빙 및 위조 방지, 부인 방지를 위한 전자 서명 인감으로서의 기능
집문서 계약도 아닌 일상의 금융거래에 인감을 반드시 요구하는 정책이 만들어진 계기는 본인 확인이 모호할 수 밖에 없는 온라인의 한계를 일시적으로 넘어서기 위함이었을 것이다. 다른 의도가 있었다고는 믿기 싫다.
그렇다면 지금 거래를 시도하는 사용자가, 자신이 주장하는 바로 그 인물임을 높은 확률로 증명해 주는 시스템을 만드는 일에만 철저히 해야 할 일이다. 지금같이 사용자에게 불리한 기능 대신, 지금 온라인에서 이 거래를 하고 있는 당사자가 오프라인의 나와 동일함을 서비스 사업자와 사용자 쌍방이 안심하고 확인하게끔 하면 그만인 것이다. 인증 자체가 뚫린 후라면, 전자 서명은 이미 아무런 효력이 없다.
그런데 모니터 앞에서 접속 중인 사용자가 정말 시스템 상의 그 사람이 맞는지 알 수 있을까? '인증'이라는 이 오랜 테마에 대한 기술적 시도는 끊임없이 이루어지고 있고, 그러한 노력의 결과물도 다양하게 상용화되고 있다. 공상과학의 단골 테마 중 하나였던 생체인식도 외국의 은행들에서는 이미 시도되고 있다.
Siemens와 스위스의 Axsionics사의 지문 인식 카드는 지문이 맞으면 암호를 알려주는 약간 두꺼운 신용카드인데, 이미 유럽과 남아프리카의 은행들이 테스트하고 있다. 이러한 첨단 기술이 비용 등의 이유로 당장 추진되기 힘들다면 이미 국내 시장이 형성되기 시작한 OTP나 HSM, 이조차 번잡하다면 핸드폰으로 보내주는 U-OTP만 있어도 이중요소인증은 일단 커버된다.
(주: OTP는 일회용 비밀번호 생성기(카드식, 토큰식 등), HSM은 하드웨어 보안 모듈. 즉 스마트카드 리더 등의 장치, U-OTP는 핸드폰을 통해서 날아오는 일회용 비밀번호라고 생각하면 편함)
어떠한 '실물'(주: OTP/HSM) 또는 이것으로 발송하는 (U-OTP) 개인 식별 번호와 내가 기억하는 개인정보의 조합은 현 시스템이 제공하지 않는 제대로 된 이중요소인증이다. 여기에 한창 탄력을 받고 있는 음성 인식 기반의 생체 인식이나, 다소 원시적이지만 전화 승인 서비스도 보조적인 역할을 할 수 있다. 우리 주위에는 현 체제를 벗어날 대안이 잔뜩 있다.
이렇게 인증이 '확실하게' 된 후라면 온라인에서 전자 서명이 필요한 순간은 오프라인에서 인감이 필요한 순간으로 한정해야 할 것이다.
또한 이 때에도 본인 인증이 충분했다는 전제로, 외국처럼 인증서가 아닌 키보드 타이핑으로 갈음하는 것도 괜찮다. 만약 정 불안하거나 꺼림칙하다면 웹이 아닌 전용프로그램이나, 음성 서명(voice signature), 영업점 내방을 유도하는 것이 올바를 것이다.
길도 있고, 대안도 있다. 우리의 선택에 의해 구조 개혁이 달성된다면 지금과 같이 은행마다 관공서마다 쇼핑몰마다 서로 다른 '구조의 확장'을 사용자 시스템에 강행하는 부조리는 대부분 해소될 것이고, ActiveX는 그 본연의 기능에 충실할 수 있도록 해방시켜 줄 수 있을 것이다.
(주: 쓰잘데기 없는 말 빼면 보안이라든지, 인증이라든지 하는 식으로 원래 의도되지 않은 목적으로 사용되지 않을 것이라는 이야기. 한국이 비스타, IE7, IE8 나올때마다 벌벌 떠는 이유는 '원래 그렇게 쓰라고 만든게 아닌 것을' 억지로 만들어 써서 생기는 문제임)
우리는 가끔 백지 위에서 더 광활한 망상을 하며 더 큰 비전을 가질 필요가 있다. 2008년, 지금은 정말 그 시점이다. 지금 이렇게 표준에 기반한 웹을 꿈꾸는 것은, 단지 다른 OS, 다른 브라우저 등을 쓸 수 있게 되어 선택지를 늘릴 수 있기 때문만이 아니라, 우리가 미처 상상하지도 못했던 다양한 방법으로 웹을 액세스하고 서비스하는 그날에 대비하기 위함이다.
온갖 모바일, 유비쿼터스 시나리오에 임베디드, 그리고 매시업에 클라우드 컴퓨팅까지. 우리는 소프트웨어와 웹이 뒤섞여 발전해갈 미래에 따라갈 수 있을까?
정말 걱정해야 할 리스크란 이런 것이다.
