금감원의 스마트폰 보안 정책

2010.01.06 글쓴이 youknowit

오늘(1월6일) 배포된 금감원의 “스마트폰 전자금융 서비스 안전대책“의 기본 방향은 “PC 인터넷 뱅킹 서비스와 유사한 보안 수준을 스마트폰에도 적용”하는 것입니다. 세부적으로,

  • 로그인: 공인인증서를 사용하거나, 비밀번호 외에 일회용 비밀번호(보안카드 포함) 등 two-factor 인증을 할 것.
  • 계좌이체: PC 인터넷 뱅킹 계좌 이체에 적용되는 거래인증 방법(비밀번호, 일회용 비밀번호, 전자서명)을 스마트폰에도 적용
  • 보안교신: “스마트폰-금융회사” 간 전 통신구간에서 암호화 교신 할 것
  • 키보드 입력값 관련: “입력정보 보호 대책”을 적용
  • 바이러스 관련: “악성코드 예방 대책”을 적용
  • 거래 사실의 부인 방지를 위해 “전자서명 등”을 이용

적어도 현행 규정(전자금융감독규정 및 시행세칙)에 비하면 조금 진전된 접근이라고 평가할 부분이 있습니다.

현행 규정은 “이용자PC에 … 보안프로그램을 설치”하라는 매우 직설적이고 편파적(플러그인 기술 편향)인 표현을 동원할 뿐 아니라, 보안프로그램을 어떻게 해서든 팔아보려는 업체 영업사원의 단순 소박한 욕망이 적나라하고 “무모하게” 규정에 그대로 드러나고 있지만, 스마트폰의 경우에는 다음과 같이 포괄적이고 중립적인 표현이 사용되고 있습니다. 즉,

첫째, “입력정보 보호대책“은 매우 다양한 기법으로 구현될 수 있습니다. 예를 들어, 서버가 스크린 키패드 기술을 구사하면 이용자가 별도 프로그램을 설치할 필요가 없습니다. 매번 다른 입력값을 요구하는 해법(보안카드 등 OTP)도 만족스런 “입력정보 보호대책”이 될 것이며, 이용자는 아무런 프로그램도 설치할 필요가 없습니다.

보안업체가 지금까지 판매하던 키보드보안 프로그램은 실제로는 무용지물이었습니다. 심지어 금융결제원 홈페이지, 인증서 비밀번호에 관한 안내에도 다음과 같이 “고백”되어 있습니다: “e-mail, 개인사이트 등의 비밀번호와 유사 또는 동일한 비밀번호는 사용하지 마세요.”

즉, 다른 계정에 사용하는 것과 동일한 비밀번호를 인증서 비밀번호로 사용하면(대부분의 이용자들이 실제로 그렇게 하고 있습니다), 키보드보안은 아무 소용이 없었습니다. 보안업체들이 과연 이 사실을 정직하게 고백한 적이 있습니까?

둘째, “악성코드 예방대책” 또한 포괄적이고 중립적인 표현입니다. 기기(device)에 따라서는 제작자가 이미 합리적 수준에서 악성코드 예방대책을 전세계 이용자에게 제공하는 경우가 있을 것입니다(아이폰, 아이팟터치 등). 이 경우에는 별도의 예방대책이 현재로는 불필요 합니다. 반면에, 안티 바이러스 프로그램 설치가 가능한 환경에서는 제대로 된 full 프로그램을 설치하도록 안내하고, 나머지 잡다한 프로그램을 함부로 설치하지 말도록 적극 권장하는 것이 기술적으로 정직한 유일한 “악성코드 예방대책”입니다.

은행에 접속해 있는 동안만 잠시 켜졌다 꺼지는 잡다한 “보안프로그램”이 사실은 “컴맹 공무원에 대한 눈가림”에 불과하다는 것은 보안 업체들도 이제는 시인하므로, 오픈웹에서 이 사실을 반복할 필요는 없겠습니다.

아이폰용 실시간 백신은 기술적으로도 불가능합니다. 무지한 국내 언론을 동원하여 아이폰용 백신 개발 운운하는 괴담을 흘린 국내 일부 보안업체는 실제로 선량한 업체들의 빈축을 사고 있습니다.

셋째, 암호화 교신을 “스마트폰-금융기관” 간 전구간에 대하여 수행하라는 권고는 너무나 당연한 것입니다. https 접속도 당연히 “스마트폰-금융기관” 전 구간에서 보안접속을 하는 방법입니다(서비스 설계만 제대로 하면). 이 부분 역시 고객이 별도 프로그램을 설치할 필요는 없습니다.

넷째, 부인 방지에 대해서도, 스마트 폰 대책에서는 “전자서명 등”을 사용하라는 식으로 훨씬 유연하게 표현되어 있습니다. “전자서명 만”을 사용하라는 것이 아닙니다. 부인 방지는 결국에는 법적, 사회적 개념입니다. 어떤 거래를 내가 한 것이 아니라고 주장했을 때, 그 주장이 어느 정도 “설득력”이 있는지의 문제이기 때문입니다.

보안카드, OTP, SMS 문자 인증 등을 효과적으로 병행 사용하여 인증과정을 “전체적으로 안전하게” 설계, 운용할 경우, 그 거래를 자신이 하지 않았다고 “오리발” 내미는 것은 어렵습니다. 요컨대, “전자서명 만”이 부인 방지 효과가 있다는 오해는 이제 불식되었고, 각 서비스 제공자가 합리적으로 판단하여, 기술적으로 수긍이 가는 다양한 해법을 채택할 여지를 열어 두는 것이라고 이해합니다.

각종 국내용 “보안프로그램”(플러그인) 판매 만을 자신의 사업 영역으로 규정하고, 그것에만 목을 매고 있었던 업체들은 빨리 퇴출되는 것이 옳습니다. 국제 수준의 보안 “시스템 설계” 기술을 확보하고, 세계 시장에서 당당히 경쟁할 능력이 있는 업체가 주목 받는 시절이 곧 올 것입니다.

금융감독원이 현명하고 유연하게 대처하시면, 그런 시절은 더 빨리 올 것입니다.

(자신도 모르게) 보안업체 영업 사원의 하수인이 되어, 각종 “보안프로그램을 이용자 PC에 우선 설치”하라는 적나라하게 부끄러운 현행 규정을 강행하기 보다는, 이 규정을 신속히 개정하여, 스마트폰 안전 대책처럼 중립적이고, 유연한 표현으로 수정하시는 것이 전자금융 거래 보안을 위한 첫걸음이 될 것입니다.

이용자 PC에 설치되는 보안프로그램(클라이언트 플러그인)에 과도하게 의존해 왔던 종래의 보안기술 경향을 이제는 폐기할 때가 왔습니다.

Categories: 보안, 정책제안 | Tags: , , , | 3 comments  오픈웹 구독 메일로 받기

  • 오리

    은행의 경우는 좀 낫지만, 신용카드의 경우 더욱 악화되고 있는 것 같습니다. 최근 모 카드의 협조 요청으로 인해 대한항공과 아시아나항공이 원래 카드번호만으로 이루어지던 승인 절차를 ActiveX로 변경하였습니다. 물론, 한국어를 쓰는 내국인 사용자에 한해서.

    사실 항공사와 같은 경우는 결국 고객의 탑승 시점에서 고객 확인을 하는 업종으로, 특별히 이러한 프로그램을 설치하라는 권고가 없습니다. – 공연, 극장 등도 인터넷에서 카드번호를 받을 수 있는 까닭이, 소액 결제여서가 아니라, 고객을 결국 대면하는 직종이기 때문에 특약을 맺어 가능하게 된 것입니다. –

    인터넷 쇼핑몰의 경우에는 이러한 제약이 더 큽니다. 쇼핑몰은 기본적으로 대면거래가 아니기 때문에 지침 상 안전결제나 안심클릭과 같은 요상한 시스템을 쓰지 않으면 안됩니다. 이런 방식을 다른 애플릿으로 만들어 우회적으로 처리하려 하는 시도를 할 수밖에 없게 만드는 국내 환경이 참 답답하지요. Paypal은 여신금융업법 위반으로 국내 서비스를 하지 못하며, 신용카드 결제는 웹 표준으로만 다 할 수 있다는 것을 VISA가 보여 주었는데도 불구하고 – 하지만 그 시스템은 불편해서 세계적으로 거의 쓰이지 않습니다. – 무작정 ActiveX에 구겨 넣는 시스템을 만드는 억지를 만들어 내지요.

    • 우분투

      알라딘과 Yes24의 경우를 보면 신용카드쪽이 상황이 더 나은 것 같은데요.

      아직 신한은행, 농협을 제외하면 IE 외에 조회, 이체 서비스가 되는 은행은 없는 것 같은데요. 농협 리눅스 뱅킹은 실제로는 사용할 수 없는 상태나 마찬가지여서 예외로 치면 신한은행 하나 있는데 웹 기술 기반이 아니라 맥 전용 뱅킹 프로그램을 배포한다고 알고 있는데요.

      그에 반해 신용카드는 브라우저만으로 결제가 가능하니까 더 낫다고 봅니다.

  • mountie

    스마트폰의 암호화 교신에서 주의할점은 상당수 모바일폰이 일명 “웹뷰어”방식의 브라우징 방식을 이용합니다. 이는 스마트폰에서 입력한 정보를 서버로 전달하고 서버에서 브라우징한 결과를 다시 스마트폰으로 돌려보내는 방식인데 스마트폰과 브라우징을 대신하는 서버구간은 보안이 상당히 취약합니다. 이문제 해결을 위해서는 “한국무선인터넷산업연합회(MOIBA)”에서 운영하는 단말정보 서버(DDR Server)를 이용하면 해결가능합니다. 단말정보 서버에는 W3C MobileOK 표준을 준수하는 단말정보를 저장하고 있으며 명시적으로 “웹뷰어” 방식의 단말은 등록하지 않는 정책을 취하고 있습니다.
    따라서 스마트폰 전자금융 서비스를 시작하기전 DDR서버를 조회하여 실질적인 암호화 교신이 가능한 단말인지 여부를 확인(응답정보에 SSL지원여부를 포함)하고 안전한 브라우징이 가능한 단말에 대해서만 서비스를 허용하는 형태의 구성이 가능합니다.
    참고사항입니다.

«

»