ActiveX외의 대안은 없는가?

2006.09.23 글쓴이 youknowit

“보안접속” 플러그인은 원래부터 필요가 없습니다. https 로 접속하면 모든 웹브라우저 이용자들이 더 안전하고, 간편하게(별도의 플러그인을 설치할 필요없이) 보안접속을 할 수 있게 됩니다. 국내 업체가 지금껏 판매해 온 별도 플러그인도 보안접속은 SSL 방식으로 하고 있습니다.

한편, “거래 내역에 대한 전자서명”은 자바 애플렛을 사용하면 됩니다. https://ms-class-action.net/class 을 방문하여, 실제로 전자서명해 보시기 바랍니다. Chrome, Firefox, Flock, MS IE, Opera, Safari 웹브라우저에서 모두 전자서명을 할 수 있습니다(윈도우/리눅스/맥). 오페라 웹브라우저는 제가 발급받은 서버 인증서를 인식하지 못하기 때문에 인증서를 믿을 것인지를 묻는 경고창이 두세번 추가로 뜹니다. 다른 주요 웹브라우저들이 모두 저의 서버인증서를 믿으니, 여러분도 믿어주시면 됩니다.

+++++++++++++++

국내 전자금융거래에서 ActiveX는 다음 용도로 사용되고 있습니다

  • 보안접속(128bit 암호화 접속)을 위하여
  • 전자서명을 위하여
  • 고객의 컴퓨터에 키보드해킹방지, 바이러스감시, 치료 프로그램을 강제 설치하기 위하여

128bit 암호화 보안접속(secure connection)을 위하여 별도의 웹브라우저 플러그인을 사용하는 나라는 현재 우리나라 뿐 입니다. 2000.7. 부터 전세계에 배포된 MS IE 5.5는 이미 128bit 보안접속 기능을 기본을 탑재하고 있습니다.(우리 업체들이 아직까지 써먹는 보안접속 플러그인은 그 직전에 개발된 것입니다. 아무 쓸데 없어진 프로그램을 아직까지 들이대는 셈입니다). 현재 파이어폭스, 오페라, 사파리 등의 웹브라우저는 256bit 암호화 보안접속 기능을 기본으로 장착하고 있습니다.

키보드 해킹방지 등의 프로그램은 ActiveX로 강제 설치할 이유나 근거는 원래 부터 없습니다. 여기 참조

그러나 거래 내역에 대한 전자서명(electronic signature) 기능은 웹브라우저에 기본으로 장착되어 있지 않습니다. 따라서, 전자서명기능 구현과 관련된 해법만이 논의의 필요가 있는 것입니다.

현재 우리 업계는 전자서명과 보안접속을 하나로 “뭉뚱그려” 수행하는 ActiveX 콘트롤을 사용하고 있다는 것은 모두 다 아시는 것이고…

ActiveX외의 대안이 여럿 존재한다는 것도 알려져 있는 사실입니다.

특히 자바 애플렛(+FLEX)을 이용한 솔루션은 국내 업체들이 이미 개발을 완료하여 시연도 마친 상황입니다:

이니텍과 리아솔루션즈가 공동으로 개발한 ‘X-SAFE’는 Mac OS X, Windows, Linux 등 주요 운영체제를 대부분 지원하며, Internet Explorer가 아닌 Safari나 Firefox, Opera 등에서는 ActiveX 대신 Java 애플릿으로 실행돼 보안/인증 절차를 처리한다. 보안 면에서도 기존 웹 애플리케이션과 동일한 수준의 데이터 암호화 및 사용자 인증 기술을 갖추고 있다.

외국 업체 역시 자바 애플렛을 사용한 전자서명 솔루션을 이미 여러해 전에 출시해 두고 있습니다(“보안접속” 솔루션은 당연히 없습니다. 웹브라우저가 훨씬 더 우월한 보안접속 기능을 장착하고 있으므로). 미국 RSA Security 사는 2002년에 E-Sign이라는 솔루션을 개발, 출시하였고 RSA 사의 일본 지사는 2003년에 일본 시장에 이를 론칭하였습니다.

자바 애플렛을 이용한 전자서명 솔루션은 공개소스로도 개발되어 있습니다.

[국내 어느 분께서 독자 개발하신 자바 애플렛(서명부착 및 인증서 로그인 처리 용도)의 소스코드도 있습니다. 여기에 있습니다. ]

오늘 소개하는 것은 덴마크 정부가 채택하고 있는 공개소스 기반의 인증서처리 솔루션입니다.

OpenOCES로 알려져 있는 이 사업은 덴마크 과학기술부가 덴마크 국영 통신사 TDC와 제휴하여 추진한 것입니다. 공인인증서 처리의 전 과정을 자바 기술로 구현한 이 솔루션은 현재 GNU LGPL(상용, 비상용을 불문하고 무료 이용, 변경, 응용 등이 가능한) 조건으로 전세계에 제공되고 있습니다. 이 솔루션을 사용하여 덴마크 국민들은 온라인 세금납부, 국영은행거래, 온라인 상업등기 등 공공서비스를 이용하고 있고, 여러 개인 기업, 온라인 결제회사, 학교 등에서도 이 솔루션을 채용하고 있습니다.

이 솔루션은 인터넷 익스플로러, 파이어폭스, 사파리, 오페라, 캉커러 등 자바를 지원하는 웹브라우저는 거의 대부분 이용할 수 있습니다.

덴마크 과학기술부가 2003년에 국영통신사(TDC)와 이 사업계약을 체결할 때 내세운 조건은 두가지 랍니다:

  • 운영체제와 브라우저 등 플랫폼에 구애받지 않고 인증서를 이용할 수 있도록 할 것
  • 개발 과정을 모두 공개하여 누구나 참여할 수 있도록 할 것

덴마크 사람들 정말 멋있지 않나요?

우리 정통부와 KT가 협력하여 GNU LGPL 프로그램을 개발하고 그 모든 결과를 CC(Creative Commons)에 입각하여 전 인류와 공유하는 그런 날은 언제 오려나?

OpenSign이 과연 어떻게 생겼는지 (유저 인터페이스가 어떤지) 궁금하신 분은 여기를 가보시기 바랍니다. 윈도우즈 이용자를 위한 테스트 사이트인데, 예를 들어 100 유로를 계좌번호 12-34-567-89 에 보낸다고 생각하고 아무렇게나 기입하신 다음 서명하기(‘Request signature’)를 클릭하면 자바 애플렛이 실행됩니다. 자신의 브라우저에 개인용 인증서가 미리 저장되어 있으면, 그것을 인식하여 그 인증서 중 하나를 선택할 수 있도록 되어 있습니다. 최초 실행의 경우에는 10초 가량이 걸릴 것이지만, 그 다음부터는 전혀 느리다는 느낌이 없을 것입니다. 매킨토시, 리눅스를 이용하시는 경우, 테스트 페이지에 관하여는 아래 댓글을 보시기 바랍니다.

[인증서 로그인이 실제로 이루어지는 페이지는 여기를 방문해 보시기 바랍니다.]

One Pingback/Trackback

  • http://openweb.or.kr keechang

    미국 육군과 국방성(DoD)도 공개소스 기반의 자바 애플렛과 스마트카드를 이용한 인증서 처리 솔루션을 2005년1월 부터 도입하였다는 군요. http://www.gcn.com/online/vol1_no1/27769-1.html
    http://www.prleap.com/pr/5937/ (보도자료)

  • http://openweb.or.kr keechang

    캐나다 통계청도 인증서 로그인을 자바 애플렛으로 하고 있습니다. 윈도즈와 매킨토시에서만 가능한 형태로 서비스가 시작되었다가, 리눅스 이용자의 요구와 문의가 있자, 수정하였다는 군요. 2006.5.4. 경에 문제 제기가 되었고, 열흘 쯤 뒤인 5.15.에 카나다 통계청은 다음과 같이 회신하였습니다:

    In response to demand, Statistics Canada has removed the restriction for Linux. This change takes effect May 13th, 2006.
    Kimberly Allaire, Statistics Canada

    우리는 이제 소장 접수를 앞두고 있습니다. 안타깝군요.

  • http://openweb.or.kr keechang

    자바 애플렛을 이용하지 않고도, 범용적으로 모든 플랫폼과 브라우저를 지원할 수 있는 방법이 가능하다는 제안도 이미 나와 있습니다.

    Demo 사이트는 여기: http://demo.webpki.org/

    XML기반으로 개발된 이 방법에 대한 간략한 기술적 설명은 http://webpki.org/WASP-tutorial.pdf 에 있습니다.

  • http://openweb.or.kr keechang

    위 본문에서 언급한 OpenSign 테스트 페이지는 윈도에서 다양한 브라우저들을 지원합니다.

    리눅스, 매킨토시에서 테스트하시려면 http://www.openoces.org/demo/index.html 에 가시면 됩니다. 먼저 자신의 인증서를 내보내기 하여서 .p12 형식의 꾸러미 파일을 만든 다음, 그파일을 선택하여 서명, 또는 인증서 로그인 테스트를 하면 됩니다.

  • http://openweb.or.kr keechang

    불가리아 국립소프트웨어 개발원의 Svetlin Nakov 교수가 개발한 자바 애플렛(인증서 서명/스마트카드 서명)의 소스코드는 http://open.unfix.net/NakovDocumentSigner.rar 에 있습니다. 자바에 관심이 있는 분들께서 이것을 이용해서 우리 오픈웹에 테스트 페이지를 만들어 주시면 고맙겠습니다.

  • photon

    http://openweb.or.kr/?page_id=54#comment-153
    에서 언급하신 webpki는 아직 구현된 것은 아닙니다. 거기에 있는 데모는 일종의 *에뮬레이션*입니다.

    webpki.org의 운영자는 S/MIME 기능이 대부분 메일 프로그램에 들어 있듯이 웹 브라우저도 이런 기능을 제공해야 한다고 생각하지만, 어떻게 될지 모르겠습니다. 많은 이가 동의해서 표준이 만들어진다고 해도 실제 (주요) 브라우저에 그 기능이 들어가려면 상당한 시간이 걸리겠지요. 이런 기능이 웹 브라우저에 들어가면 따로 Java applet(혹은 한국에서 현재 하듯이 IE에서만 쓸 수 있는 ActiveX) 등을 만들지 않고서도 web signing을 할 수 있겠지요.

  • http://openweb.or.kr keechang

    오픈웹에 참여하시는 어느 분께서 제게 보내오신 자료를 소개합니다:

    browser에 이미 embeded된 전자서명 tool이 많이 있습니다.

    Firefox 브라우저로(OS관계없이)
    https://trustcenter.paygate.net 에 접속한 다음, User ==> Test Certificate를 선택하여 sign 버튼을 클릭하면 browser에 embeded된 signing tool이 뜹니다. 이런 방식은 mozilla나 netscape에서도 동일하게 동작합니다.

    그리고 MSIE에는 CAPICOM이라는 free library가 존재하여 마찬가지로 쉽게 서명할 수 있도록 제공합니다. 여기서 소스를 다운받아 압축풀고 html demo로 시험해 볼 수 있습니다.

    java applet 을 사용하지 않더라도 대안은 많이 있으며 저에게는 protocol의 표준문제가 더 중요해보입니다.

    [제가 추가]: ‘프로토콜 표준문제’에 대하여는 여기를 참조.

  • http://blog.naver.com/sunyi233 이상선

    ActiveX는 그냥 윈도우에서 도는 app일 뿐입니다. 다만 IE 뒤에서 돌기에 마치 웹용 app인 것처럼 착각될 뿐이죠. 이것은 IE 종속을 넘어 윈도우 종속적인 것입니다.

    한 국가가 운영하는 공적인 서비스가 한 회사의 제품에 맞춰져 있다는 것은 많은 것을 깊게 생각하게 하는 부분입니다.

  • T. K.

    정보통신부 스파이웨어 기준 개정 및 사례집 배포
    http://www.mic.go.kr/user.tdf?a=user.board.BoardApp&c=2002&board_id=P_02_02_01&seq=5685&ctx=&bad=&isSearch=&searchVal=&basic=&npp=10&cp=1&pg=1&mc=P_02_02_01

    이용자 동의없는 액티브X 설치..”스파이웨어”
    포털사이트에서 비교적 쉽게 찾으실 수 있으므로 기사 링크는 따로 하지 않겠습니다.

    이러한 것들이 국내 웹환경에 어떤 영향을 미칠지 모르겠네요.과연 실질적인 효과가 있을까요? 아니면 눈 가리고 아웅이 될까요?

  • T. K.

    링크가 너무 길어서 ‘링크 주소 복사’ 같은 걸 이용해서 보셔야 할 듯합니다.

  • T. K.

    많은 분들이 이미 보셨을 것 같지만 혹시나 싶어 링크합니다.

    스파이웨어 사례집
    http://www.boho.or.kr/infor_data/Spyware2007.pdf

  • gomibak

    글쎄요, 이것이 얼마나 유용할지는 잘 모르겠지만, 가령 은행 사이트에서 깔도록 강요하는 액티브액스는 동의를 하지 않으면 다음 단계로 진행이 안되는 것이 문제이지요. 그로 인해, 많은 사람들이 무작정, 습관적으로 승인 단추를 눌러대게 된 것은 아닐지. 새삼스럽게 동의없으면 스파이웨어라니…은행에 스파이웨어 안깔았다고 면죄부 줄 일도 아니라고 생각됩니다만.

  • AppleADay

    통계(http://news.bbc.co.uk/1/hi/health/5224306.stm)에 의하면 덴마크가 행복한 나라라고 하는 군요. 위의 글을 보니 그럴만도 하겠네요 ^^

    미국 최대은행인 Bank of America도 ActiveX같은 것을 안 쓰는데 왜 한국은행들은 뭐가 잘나서 자기들만의 프로그램을 강제로 사용하게 하는 걸까요? 자기들이 제공하는 프로그램이 더 안전하다는 보장을 뭘 믿고 하는 건지…새로 나올 iPhone 3G는 BOA도 접속해서 온라인뱅킹 한다던데…

  • 오픈웹지지

    쇼핑몰을 통해 물건을 한개 살려고 했더니, 결재단계에서 ActiveX설치를 요구하길래 설치했더니,,, 인터넷 옵션의 신뢰할 수 있는 사이트에 온갖 잡스런 카드,은행,보안프로그램 사이트를 다 등록시켜 놓고 인터넷 보안 옵션도 마음대로 조절해 놓은걸 보고 기겁했습니다…

  • Revi

    Iphone에는 jvm이 없습니다. flash는 요원한 일이고 포팅될 일도 없을듯 합니다.
    activex를 반대하신다면 java도 반대하심이 옳은일 아닌지요.
    덧붙여, 브라우저 플러그인 또는 브라우저 임베디드 컴포넌트는 브라우저에 종속됩니다.
    위의 것들은 역시 표준과는 거리가 멉니다.

    • Figo

      만약에 Java도 특정 플렛폼에 종속이었다면 activex와 같이 반대의 대상이 되어야 겠지요. 요지는 바로 특정 회사에 종속적이며, 특정 플렛폼에 종속적이고, 보안상 그 위험성이 이미 증명된 것에 대해서 사용을 반대하는게 그 요지가 아닐까요?

  • http://openweb.or.kr youknowit

    Revi/ 저도 동감입니다.

    이 글의 의미는, “전자금융거래에는 공인인증서를 반드시 사용 하도록” 강제하는 황당한 현행 법 제도 하에서, 그리고 데스크톱 환경에서는, 대안이 존재한다는 정도에 그칩니다.

    “전자서명을 꼭 해야 안전하다”는 주장 자체는, 저는 전혀 동의하지 않습니다. 전자서명은 authentication/non-repudiation 기능(신원확인/부인방지 기능)을 수행할 뿐, 접속의 보안과는 무관합니다.

    전자서명 외에도 무한히 다양한 신원확인(authentication) 기능이 있으며, 부인방지 기능은 현재로서는 “거래내역 서명” 외에는 뚜렷한 대안이 없지만, 서명을 안한다고 해서 교신의 안전(security)가 약화되는 것은 전혀 아닙니다.

    충분한 수준의 authentication 을 거쳐 거래가 이루어졌다면, 비록 전자서명이 사용되지 않았다 하더라도, 일방이 나중에 그 거래 내역을 부인해 본들, 법원을 설득하기에는 역부족입니다.

    서명이 있으면, 거래 내역을 부인하는 것이 현실적으로 거의 불가능하지만, 반대로, 서명이 없기만 하면 무조건 거래 내역을 부인할 수 있는 것이 아닙니다.

    휴대폰에서는 전자서명 없이 거래하는 것이 현재의 기술 수준으로는 당연하고, 굳이 전자서명을 강제해야 할 아무런 합리적, 정책적 이유도 없습니다.

    물론, 세계 최초로 우리 기술진이 “휴대폰에서의 거래내역 서명 솔루션”을 개발해보겠다는 원대한 목표를 세우고 노력하는 것이야 누가 말리겠습니까만, 기술을 별로 모르는 금감원 공무원이, 휴대폰 거래에서도 공인인증서 사용을 의무화하는 것을 검토해 보겠다는 식의 태도를 취하는 것은 옳지 않습니다.

  • http://snowall.tistory.com snowall

    마지막 부분은 정말 공감합니다. 공무원이 기술을 잘 알면 좋겠지만, 잘 모른다면 다양한 분야의 전문가에게 자문을 구했으면 좋겠네요.

  • http://blog.naver.com/fstory97 숲속얘기

    은행은 잘 난게 아니라.. 귀찮은거겠죠. ㅎㅎ 아마도 어디 한군데가 “우린 이거 했다” 하는 순간 부터, 다른 은행들도 너도 나도 시작할겁니다. 정부에서 웹접근성인가 뭔가 한다고도 하고. 무엇보다도 모바일시장이 커지면 두번 개발하기 귀찮아서라도 모바일과 혼용가능한 솔루션을 채택할겁니다.

  • 실무자

    금융감독원 전자금융안전대책기준(2000.9)에 의거하여 금융정보는 국가에서 안전하다고 평가한 알고리즘으로 암호화 해야 합니다. 전자금융안전대책기준에는 실제 예로 SEED 128 Bit 를 들고 있습니다.

    SSL 의 경우 아래와 같은 단점이 존재해 금융권에서는 사용되지 않습니다.

    -. 국가에서 안전하다고 인정한 알고리즘의 경우 윈98 등에서는 지원하지 않는다.(최소 AES 정도는 지원해야 합니다.)
    -. SSL 은 사용자 인증 시점이 보안 핸드쉐이킹이라서.. 업무에서 필요한 순간(예 : 로그인 버튼 클릭)에 클라이언트 인증서를 받을 수 없습니다.
    -. SSL 로는 전자서명 자체가 불가능합니다.
    -. 알려진 SSL 관련 보안 취약점이 너무 많이 존재합니다.(SSL Strip/서버 인증서 용도 검증 취약점을 이용한 MITM 등등)

    과거 은행에 도입된 암호 제품들은 SSL 보다 보안성에서 많이 떨어졌으나, 최근 보안 제품들은 SSL 보다 강력합니다.

    ActiveX 가 이슈가 되는 것은 아마 IE 에서만 뱅킹이 가능해서가 아닌가 싶은데…
    이미 보안 업체들이 멀티플랫폼에 대한 보안 모듈 개발을 마친 상태입니다.

    중요한 것은 은행의 결정에 달린 것인데…
    아시다시피 은행에 리눅스/MAC 을 지원할 인력이 없습니다.

    더욱이 저희가 경험해본 결과 리눅스 사용자의 경우 일반 사용자가 아닌 컴퓨터 전문가들로…
    대부분 커널을 자기 입맛대로 컴파일 해서 쓰는 등의 환경인지라 뱅킹용 암호 모듈이 제대로 돌지 않는 경우가 많았습니다.

    은행 돈도 많은데 리눅스/MAC 교육을 시켜
    인력을 충원하면 된다고 생각하시겠지만…

    은행도 기업인지라 투자대비 수익면에서…
    좋지 않으면 안하는 것이 당연합니다.

    자기 스스로 커스터마이징한 리눅스 사용자를 위해
    은행직원이 하루종일 붙어서 그 사람 뱅킹을
    가능하게 PC 점검해주고 있어야 할까요?

    MAC 사용자의 경우 리눅스 사용자와는 달리
    일반인 그룹이 다수 존재하므로…
    신한은행의 경우 MAC 용 EZPLUS 라는 CS뱅킹
    프로그램을 배포 하고 있습니다.

    그리고 자바 에플릿을 예로 드셨는데…
    자바 에플릿은 위험합니다.
    자바 에플릿 자체를 디컴파일해서…
    수정후 서명해서
    클라이언트에 다시 심어 놓으면
    얼마든지 거래를 위험하게 만들수 있기 때문입니다.

    보안은… 못하게 하는게 아니라..
    어렵게 하는데 초점을 두고 있는 것입니다.

    이상 실무자의 ^^ 이야기였습니다.

    저에게 메일 주시면 많은 궁금하신점을
    답변해 드리겠습니다.

    오늘도 안전한 금융환경을 만들기 위해 노력하고 있습니다.

    긴글 읽어주셔서 감사합니다.

    • pc

      주장에 대한 근거 자료 부탁 드립니다.
      ——————————————————————————-

      -. 국가에서 안전하다고 인정한 알고리즘의 경우 윈98 등에서는 지원하지 않는다.(최소 AES 정도는 지원해야 합니다.)
      -. SSL 은 사용자 인증 시점이 보안 핸드쉐이킹이라서.. 업무에서 필요한 순간(예 : 로그인 버튼 클릭)에 클라이언트 인증서를 받을 수 없습니다.
      -. SSL 로는 전자서명 자체가 불가능합니다.
      -. 알려진 SSL 관련 보안 취약점이 너무 많이 존재합니다.(SSL Strip/서버 인증서 용도 검증 취약점을 이용한 MITM 등등)

      과거 은행에 도입된 암호 제품들은 SSL 보다 보안성에서 많이 떨어졌으나, 최근 보안 제품들은 SSL 보다 강력합니다.

    • pc

      ActiveX 가 이슈가 되는 것은 아마 IE 에서만 뱅킹이 가능해서가 아닌가 싶은데…
      이미 보안 업체들이 멀티플랫폼에 대한 보안 모듈 개발을 마친 상태입니다.

      중요한 것은 은행의 결정에 달린 것인데…
      아시다시피 은행에 리눅스/MAC 을 지원할 인력이 없습니다.

      더욱이 저희가 경험해본 결과 리눅스 사용자의 경우 일반 사용자가 아닌 컴퓨터 전문가들로…
      대부분 커널을 자기 입맛대로 컴파일 해서 쓰는 등의 환경인지라 뱅킹용 암호 모듈이 제대로 돌지 않는 경우가 많았습니다.

      은행 돈도 많은데 리눅스/MAC 교육을 시켜
      인력을 충원하면 된다고 생각하시겠지만…

      은행도 기업인지라 투자대비 수익면에서…
      좋지 않으면 안하는 것이 당연합니다.

      자기 스스로 커스터마이징한 리눅스 사용자를 위해
      은행직원이 하루종일 붙어서 그 사람 뱅킹을
      가능하게 PC 점검해주고 있어야 할까요?

      MAC 사용자의 경우 리눅스 사용자와는 달리
      일반인 그룹이 다수 존재하므로…
      신한은행의 경우 MAC 용 EZPLUS 라는 CS뱅킹
      프로그램을 배포 하고 있습니다.

      그러니까…웹 브라우저에 기본 내장된 https 를 사용하자는 거 아닙니까. 실무자님께서는 보안 채널과 전자서명을 분리해서 생각하는 방법을 배우셔야 할 것 같습니다.

    • 98?

      아. 그러니까 윈도 98의 지원을 위해 30%를 무시하신다는 거죠? 퍽이나 남을 배려하는 정책이네요. 참~ 잘 읽었습니다. 퉷

  • T. K.

    실무자// 쓰시느라 수고는 하셨는데 역시 기존 입장에서 한 발짝도 나간 게 없군요. 쓰신 얘기는 여기 과거글에도 이미 몇 차례 언급되어 있습니다.

  • 실무자

    pc 님… SSL 취약점은 구글에서 SSL vulnerability, SSL Strip 등의 키워드만 쳐도 많이 나오고…
    전자금융안전대책기준 도 네이버에서 치면 나옵니다.
    그리고 은행에서 사용중인 보안 제품의 상세 프로토콜은, 개인적으로 부탁하시면 오프라인상에서 하드카피로 공개해드릴수 있으나, 웹 사이트에 올릴순 없습니다.

    그리고 브라우저에 내장된 https 를 쓰자고 하셨는데… 위에 SSL 의 취약점을 들면서 쓰면 안되는이유를 위에 적어놨습니다…

    그리고 브라우저에 내장된 https 를 쓰다가 보안적 문제가 발생하면 책임질 사람이 아무도 존재하지 않습니다. MS 가 책임질것 같습니까? 커스터마이징도 거의 불가능하죠.

    보안 업체에서 만든 보안 제품/프로토콜 상에 문제가 생기면 보안 업체가 책임지고 문제를 해결합니다만… HTTPS/SSL 의 경우 아무도 책임지지 않습니다. 본인이 보안 담당자라도 그것을 선택하겠습니까?

    언론은 작은 보안문제만 생겨도 크게 확대해서 뉴스를 냅니다. 만약 SSL 의 작은 문제를 크게 확대해서 뉴스 나오면 뱅킹 운영/보안 담당자는 뭘 어떻게 해야합니까? 문책 당하고 짤려야 합니까?

    그리고 저에게 보안 채널과 전자서명을 분리해서 생각하는 방법을 배우라고 하셨는데 ^^;;; 보안 전공(그것도 암호 프로토콜 전공)하고 실무한지 10년된사람입니다. 그걸 구분 못하겠습니까?

    ActiveX 를 반드시 써야 하는 이유는
    -. 국가에서 안전하다고 인정한 알고리즘을 MS 윈98 의 HTTPS 가 지원하지 않기 때문에.. 별도로 커스터마이징한 보안 프로토콜이 필요할 수 밖에 없고..
    -. 공인인증서와 연계헤서 인증/전자서명을 안전하게 할수 있는 코드가 디컴파일과 분석이 어려운 C로 컴파일된 실행파일어야 하고, 웹 환경에서 지원 가능해야 하며…(인터넷 뱅킹이니깐요.)
    -. 기타 키보드 보안/방화벽 등 도 사용해야 하기 때문입니다.

    마지막으로 한가지 업계 정보를 알려드리도록 하죠.
    1. ActiveX 자체를 사용하지 않아도 되는 CS 형태의 뱅킹 지원 브라우저가 개발되고 있습니다. 이 전용 브라우저는 아직 시작단계여서 MS 윈도우만 지원하지만 몇년안에 모든 플랫폼을 지원할 예정입니다.(물론 수요가 너무 없으면 ROI 가 안맞으니 MS 윈도 이외의 플랫폼 개발이 어려워질수 있겠죠.) 아마 은행에서 배포하는 전용 브라우저는 은행만 이용 가능하겠지만… 만약 개인 수요가 있어 제한이 풀린 브라우저를 개인이 직접 구매하면 모든 웹 사이트를 이용할 수 있을겁니다.(근데 과연 수요가 있을지 ^^;)

    2. 현재 SSL 보다 강력한 암호 프로토콜을 국내 금융권 내부에서 국내 업계/학계 최고 전문가로 구성된 컨소시엄을 통해 개발되고 있습니다. 아마 내년쯤 출시되는 뱅킹용 암호 제품에 반영이 될겁니다.

    3. ActvieX 를 아주 없애진 못하겠지만 없애려는 노력을 보안 업체가 하고 있습니다. 일 예로 프로토콜 Layer 에서 구동하는 보안모듈인 INISAFE Web v7 의 경우 웹 상에서 편리한 설치를 위해 ActvieX Installer 가 존재하는 것이지… 실제 모듈은 웹 상에서 전혀 ActiveX 로 구동되지 않습니다. 즉, 웹 페이지 상에 보안 모듈을 돌리는 가 존재하지 않습니다. 물론 설치페이지에서 자동 설치를 위한 Installer 의 는 존재합니다.

    4. 위 글에서 말씀드렸듯이 리눅스/MAC 에서 구동가능한 보안 모듈은 만들어져 있습니다. 그런데 베타 테스트를 원하는 은행이 없습니다. 그래서 알파버전에 머무르고 있는게 좀 안타까운 현실입니다. 은행은 어디까지나 기업논리에 의해서 뱅킹을 운영한다고 생각하시면 됩니다. 물론 정책에 의해 어쩔수 없이 뭔가를 도입하는 경우는 있습니다. 금감원에서 모든 플랫폼 지원하라고 한마디만 하면 은행도 어쩔수 없이 합니다. 하지만 그런 강제 조항이 없다면 여러분들도 은행 담당자 입장에서 생각해보면 도입을 좀 꺼리게 될겁니다.

    또 궁금하신점 있으면 의견 주세요.

    • 98?

      10년된 고물 SEED던가 PEED던가 하는 것은 128비트지만, SSL은 256비트입니다. 저기요. 그러면 외국은 어떻게 그렇게 액티브X 없이도 금융권에 잘 접속할 수 있나요?
      Inisafe Web에 대해서 말씀하셨는데 그럼 왜 설치를 ActiveX를 통해 설치를 해야 하죠?

      도대체 왜 윈도 98을 위해서 우리가 윈도 비스타나 7을 쓰면 안 되는지 정말 궁금합니다.

    • pc

      윈98 보다는 비스타 32비트의 완벽 지원이 더 시급할 것 같습니다.
      어울러 같은 회사의 보안 모듈끼리 버전 때문에 충돌하고 재설치해야 되는 문제가 발생이 되기도 합니다.

      한가지 업계 정보를 알려드리도록 하죠.
      XP 판매 중단 기사 나왔던데. 그리고 윈도우7, 올해 10월에 발매 예정이랍니다.

  • 실무자

    98 님 해외 환경은 아시다시피 ActiveX 도 없고 우리나라에서 그 흔한 키보드보안이나 방화벽도 없습니다. 그럼 안전한거라고 보시는건지요? ^^

    외국에서는 사고나면 그냥 은행이 다 책임져 줍니다. 은행 또한 보상을 위해 보험도 가입되어 있습니다.(아쉽게도 우리나라는 그런걸 하는 보험사가 없죠.) 이용자도 별로 많지 않습니다. 그래서 별로 언론의 가쉽거리도 안되구요.
    실제로 키보드 후킹에 의한 사고가 빈번합니다.

    그리고 SSL 이 256 비트를 지원한다고요? ^^
    SSL 스팩 은 당연히 256 비트를 지원합니다.
    하지만 윈98은 물론 윈XP IE6 등이 지원하는
    HTTPS는 SSL v1.0 이고(v1.1 이 좋습니다.)
    3DES 나 RC2/RC4 등 “국가에서 안전하다고
    인정하지 않은 대칭키 암호 알고리즘” 을
    지원합니다.

    저도… 금감원에서 윈도우 비스타 이상 사용자만
    뱅킹 이용해라 라는 지시 떨어졌음 좋겠습니다. ^^
    (근데 윈XP 나 윈98 사용자 아직 많거든요 ^^;)

    음 그리고 INISAFE Web v7 이 ActvieX 로
    설치하는 이유는 위에 언급했듯 편리한 설치 때문이죠…
    노란색 타이틀바 하나 클릭하면 되니깐요.
    반면 수동설치 모듈은 다운받아서 설치하고
    브라우저도 다시 껐다 키는 등의 불편함이
    존재하잖아요. ^^

    그리고 Installer 가 한번 설치되고나면 자동으로
    사용자의 클릭 엑션 없이 모듈에 대한 업그레이드가
    되기 때문에도 ActiveX 를 페이지상에 쓴는겁니다.

    오픈웹에서 보면 주로 해외사례! 해외사례!를
    외치는데… 국제 PKI 포럼 가보면 공인인증서보급율이나 인터넷 뱅킹 보편화 빈도, 보안 강화면에서 보면…
    우리나라가 단연 1등입니다.
    국가별 발표할때도 항상 먼저 발표합니다.
    그리곤 정말 자랑스럽게 숫자로 다른 나라 기를
    누릅니다.

    실무자 입장에서 사람들이 해외사례 해외사례 하는건…
    후진국 사례를 드는거랑 별반 다르지 않습니다.

    삼성전자 휴대폰개발팀에 가서 중국 휴대폰
    좋다고 외치는 거랑 비슷하다고 보시면 됩니다.

    보안은 강화될수록 편의성이랑은 거리가 생깁니다.

    인터넷뱅킹 이용자 대비해서 보안 사고율로
    따진다면 역시 우리나라가 가장 안전합니다.

    오픈웹의 존재로 보안 업계도 많이 변화되고
    있습니다. 좀더 편리하고 안전한 금융 환경이
    되도록 노력하고 있습니다.

    • 98?

      98 사용자가 많다니요? 지금은 2001년이 아닙니다. 꿈 깨세요.

    • 98?

      IT후진국 메이커님, 제발 부끄러운 줄 아세요. 보안이 강화될수록 편의성이랑은 거리가 생깁니다라고 하시지 마시고, 보안이 강화될수록 2001년 브라우저를 사용해야 합니다라고 말하는 게 정상 아닌가요?

      그리고 비스타에서는 그게 과연 편할 지 궁금하네요. 또 맥과 리눅스는 그게 과연 편할지 진짜진짜진짜로 궁금하네요. 궁금궁금~

    • pc

      국제 PKI 포럼 가보면 공인인증서보급율이나 인터넷 뱅킹 보편화 빈도, 보안 강화면에서 보면…
      우리나라가 단연 1등입니다.
      국가별 발표할때도 항상 먼저 발표합니다.
      그리곤 정말 자랑스럽게 숫자로 다른 나라 기를
      누릅니다.
      PKI 포럼 회원국이 몇 개국인지 궁금합니다.

      인터넷뱅킹 이용자 대비해서 보안 사고율로
      따진다면 역시 우리나라가 가장 안전합니다.
      구체적인 비교, 통계, 논문 등에 대한 자료 링크 부탁합니다.

      • pc

        blockquote 조작이 미숙하여 답글이 이상하게 달려 다시 씁니다.

        >

        국제 PKI 포럼 가보면 공인인증서보급율이나 인터넷 뱅킹 보편화 빈도, 보안 강화면에서 보면…
        우리나라가 단연 1등입니다.
        국가별 발표할때도 항상 먼저 발표합니다.
        그리곤 정말 자랑스럽게 숫자로 다른 나라 기를
        누릅니다.

        PKI 포럼 회원국이 몇 개국인지 궁금합니다.

        >

        인터넷뱅킹 이용자 대비해서 보안 사고율로
        따진다면 역시 우리나라가 가장 안전합니다.

        구체적인 비교, 통계, 논문 등에 대한 자료 링크 부탁합니다.

  • 실무자

    98 님.. 은행 이용자중 10%가 아직 98 사용자 입니다.
    저희도 98은 안전하지 않은 OS 로 분류해서 포기하자고 목소리를 높이고 있습니다만… ^^; 95 포기할때만큼 힘든것 같습니다.(그래도 조만간 가능하지 않을까요?)

    인터넷뱅킹은 98님 처럼 똑똑하신 분들도 사용하시지만.. 정말 컴퓨터에 컴자도 모르시는 어르신분들도 많이 사용하시고… 그분들 컴을 보면 정말 펜3에 98 쓰시는 분도 많습니다. 또한 윈도우XP 쓰시더라도 윈도우 업데이트 한번도 안하신 분들도 많이 계십니다.(IE 5.5) 은행이 똑똑한 분들의 편의를 위해 그분들은 인터넷 뱅킹 쓰지 말아야 하는건지요?

    그리고 윈 98 을 은행이 포기하더라도 ActiveX 를 아예 없애진 못합니다.

    리눅스/MAC 의 경우에 기 개발된 보안 제품도 XPCOM 과 코코아 라는 기술을 사용합니다.
    결국 ActiveX 랑 다른게 없는거죠.

    편리하다는 기준이 여러 ActiveX 를 클릭클릭 해서 PC 에 설치하는것이 귀찮은건지요? 그럼 은행이 하나의 ActiveX 가 모든 기능을 하게 해주면 불만이 없어지겠는지요?

    그리고 혹시 브라우저 자체 기능만으로만 보안이 충분하다고 생각하시는 것이면 정말 위험한 생각을 가진겁니다. 1년에 인터넷 뱅킹을 통해 거래 되는 금액이 4800조 나 됩니다. 외국은 거기에 1/10000 도 안됩니다.

    위에도 설명했지만 브라우저에 있는 보안 기능만으로 뱅킹을 운영해서 사고난 경우 책임질 사람이 아무도 없습니다. 그걸 선택한 담당자가 책임지는겁니다.

    98님이 은행담당자라고 한번 생각해보세요. 본인이 책임지고 HTTPS 만 써서 문제 없다고 보장할 수 있는지… 문제 생겼을때 과연 MS 사나 FireFox 제작그룹에서 책임 지고 문제를 능동적으로 해결할지도요.

    뚫지 못하는 보안은 이세상에 없죠. 단지 좀더 뚫는 것이 어렵게 할 뿐입니다. 키보드 보안 무력화, 방화벽 무력화 가능합니다. 하지만 쉽지 않은거죠.

    그리고 이미 보안 조치가 되어있는데 더 고도의 해킹기술이 나와 뚤린거랑… 아예 조치를 안하고 있다가 당하는 거랑은 엄청난 차이가 있습니다.

    불평만 하지마시고… 본인이 생각하시기에 괜찮은 방법이 있다고 보시면 제안을 해주세요.

    더 좋은 방안이 있으면 실무에 적극 반영할 의사가 있습니다.

    • 이용자

      -은행 이용자중 10%가 98 사용자라는 것 좀 아이러니 하네요. 물론 없진 않지만 1% 이하로 알고 있고, 은행은 아니지만, 보편적인 통계 접속 브라우저 통계에 윈98이 아무리 높아도 1%를 넘은 적을 본적이 없습니다.
      -디컴파일 어렵기 때문에 c나 active-x로 해야 한다고 합시다. 악의적인 보안 개발자가 있어 내용을 다 아는 경우는 무용지물이 되는건가요?
      -삼성전자는 해외에서 팔리는 기사라도 봅니다. 우리나라가 보안SW 강국이라면, 왜 우리나라 은행처럼 사용하는 외국은 없는건지 묻고 싶습니다.
      - 신한은행 인터넷 계좌이체시 서버 복호화 오류 또는 다시 이용하십시요 라는 20~30% 빈도 오류 메시지로 고생하는 사용자 드림.

    • pc

      >

      1년에 인터넷 뱅킹을 통해 거래 되는 금액이 4800조 나 됩니다. 외국은 거기에 1/10000 도 안됩니다.

      여기에 대해서도 구체적인 비교 자료, 연구, 논문 등의 링크 부탁드립니다. 외국의 어느 나라인지, 또는 나라들인지 궁금합니다.

    • http://hirameki.blogspot.com hirameki

      휴….. 코코아 가 기술이라….
      뭐 사소한것은 그렇다 치고….

      일단 무조건 깔고보는 윈도우 프로그램인(플러그인도 아닌 윈도우 프로그램) 액티브 엑스처럼 다른 운영체제에 있는 별도 프로그램만 눈에 들어오시는 모양인데…. 제가 외국이라 한마디 하자면, 일단 브라우저만으로 대부분이 처리 가능하기 때문에 별도로 개발된 프로그램들은 그냥 덤입니다.
      애초에 마구잡이 설치를 안하기 때문에 사람들이 뭔가 설치하는 것에 대한 경계심이 있습니다..
      내가 뭘 쓰겠다고 하지도 않았는데 마구 설치하려고 하면 일단 “아니오”부터 선택하고 본다는 말입니다.

      그럼 우리나라 사람들은 왜 그냥 습관적으로 예 를 눌러대는 것일까요? 파블로프의 개 실험은 아시는지 모르겠습니다.
      파블로프의 개 실험에서는 일방적으로 벨이 울리고 먹이가 나옵니다. 벨이 울리는 소리를 듣지 못하면 먹이가 나오지 않을것이라 생각하여 보통 상태이지만, 벨이 울리면 먹이가 나올거라 생각하여 위액이 분비되는 양이 늘어나는 것이지요.

      대강 짐작하셨겠지만, 컴을 잘 모르는 사람들이 무조건 예 를 누르게 만든 것은 서비스 제공자 측입니다.
      보통 컴퓨터를 처음 만져보시는 분들은 뭔가 설치하려고 하면 설치해도 좋은것인지 망설입니다. 하지만, 님이 예로 드신 분들은 이미 훈련이 되어있어 뭔가 설치해야 한다는 창이 나오면 무조건 예 를 누르는 사람들이라는 점입니다.
      물론 보안에서는 무조건 예를 누르는 경우도 염두에 두어야 합니다만, 윈도우즈 내에서 프로그램들끼리 경쟁해봐야 결국은 먼저 점령한 쪽이 이긴다는 것과 현행 보안 모듈도 돌파가 불가능하지 않다는 사실을 염두에 두셔야 할 것입니다.

      그렇기 때문에 뭔가 항상 설치하는 것이 아닌, 뭔가 항상 설치하지 않는데 뭔가 설치되려고 하는 상황을 사용자가 경계할 수 있도록 해 주어야 한다는 것입니다. 정상적인 프로그램 100개 중에 1개가 나쁜 프로그램이라고 해도 예 를 100번 누르는 상황에서 사용자가 일일히 확인은 힘듭니다만, 한번도 예 를 누를 필요가 없는 상황에서 한번이라도 질문이 나타나면 확인해보는 것은 비교적 쉽기 떄문입니다.
      이것은 불편하거나 편하거나를 떠나서 보안적인 장치를 무감각하게 무시하도록 사람들을 훈련하는 행위를 하지 말자는 것입니다.
      게다가 윈98이용자가 10%인데 버리지 못한다는 것은 여태까지 파이어폭스등의 브라우저를 지원하지 않는 행동과는 모순된 행동인데다가, 모든 플랫폼에서 지원되는 방법을 추가적으로 지원하기만 하면 기존의 플랫폼에는 아무런 영향도 없다는 사실을 간과하는 것에 지나지 않습니다.

      실제로 개인적으로는 국내 보안업체가 만들었다는 프로그램의 신뢰성에 대단한 의문을 지니고 있는 편이기도 하고, 그것은 소스가 납득할만한 설계가 되어있는지 확인이 불가능하다는 점에서 더더욱 그렇습니다. 소스를 공개하라는 소리는 아니지만 운영체제자체의 디자인이 덜 안전한 상황에서 구멍을 많이 막았기 때문에 안전하다 라는 이유로 윈도우즈 플랫폼에서 자신들의 프로그램을 사용한것이 제일 안전한 것인 양 선전하는 모습은 그다지 사용자의 보안을 생각하는 모습으로 보이지 않습니다.

      실제로 바이너리 코드를 함부로 다운로드하지 못하고, 설사 다운로드시키는데 성공했다고 해도 유저가 실행을 승낙하기 전까지 실행이 불가능한 OSX에서 아무런 플러그인 없이 인터넷 뱅킹을 하는 것과, 예 버튼 한번으로 원하는 프로그램과 원하지도 않는 프로그램이 패키지로 깔려서 자동으로 실행가능한 환경에서 보안프로그램뿐만이 아닌 예상할 수 없는 수많은 프로그램을 설치한 상태에서 인터넷 뱅킹을 하는 것 중 어느쪽이 더 안전한지 상당히 의문스럽습니다.

      오히려 보안보다 자신들이 편의를 생각하는것이 현행 보안업체의 보안모듈이 아닌가 생각이 듭니다.
      예 한번으로 여러개의 프로그램을 마구 설치할 수 있는 방법을 쓰면서 사람들을 보안에 더더욱 무감각하게 훈련시켰으니까요.
      게다가 그 방법 자체가 운영체제에 구멍부터 뚫고 시작하는 방법이니 말입니다.

      또 자바에 거부감이 좀 있으신 것 같은데, 자바는 규격일 뿐이고 어디것을 가져다 써야하는 것도 아닙니다.
      즉 자바규격을 만족하는 JVM을 직접 만드셔도 된다는 말입니다. JAVA는 규격만 지키면 됩니다. 모든 플랫폼에서 규격을 제대로 지키는 JVM을 구현만 한다면, 또 라이브러리 구축만 된다면 플랫폼에 관계없이 돌아갈 수 있다는 면에서 통신 프로토콜과 성격이 크게 다르지 않습니다. 그러니까 윈도우하고 맥만 달랑 지원하는 외다리 실버라이트라도 리눅스에서 동일 규격을 문라이트라는 이름하에 개발되고 있습니다. 플래시도 플래시 플레이어가 구현되면 모바일 기기도 돌아갑니다. (물론 자바도)

      그러나 자바가 선호되는 것은 특정 회사가 개발한 제품에 의존하는 것도 아니고, 규격만 잘 따르면 잘 돌아가게 되어있기 때문입니다. 플래시나 실버라이트 등은 이런 점에서 해당 회사가 개발하지 않으면 잘 안돌아가는 면이 있습니다.
      그리고 자바 어플릿은 브라우저상에서만 가동되고 운영체제에 대한 간섭은 극히 제한되어있습니다.

      너무 길어져서 요약하자면
      1. 현행 보안 모듈은 보안장치를 무력화하도록 사용자를 훈련한다. (파블로프의 개)
      2. 현행 보안 모듈은 운영체제의 기본 보안레벨을 낮추어 보안 구멍부터 뚫고 시작한다.
      3. 현행 보안 모듈은 개인 인증 + 통신 암호화를 제공하지만 통신 암호화 면에서는 SSL보다 암호화 레벨이 떨어지고
      동등한 레벨의 암호화 기술을 개발할 의지도 없다.
      4. 악성 코드가 보안 프로그램보다 먼저 기동할 수 있도록 운영체제를 조작하거나 인증서 자체를 훔치는 것 등에 대한 보안은 현재 보안모듈을 설치하지 않고도 운영체제 기본의 보안설정으로 의심스러운 프로그램의 무작위 설치 없이 사용을 유지할 수 있도록 하는 편이 더 안전하다.(중요)

      대안, (여태까지 오픈웹에 여러번 올라왔던 내용들이라 보지만…)
      1. 운영체제의 본래의 보안레벨을 올려도 문제없이 돌아가는 시스템으로 전환한다. 현재 하던대로 백신 사용도 권장한다.(외산 백신하고 충돌할수도 있지만….)
      2. 키로거 등이 걱정되는 경우에는 버추얼 키보드 등의 대안을 제시한다.
      (웹 화면의 랜덤하게 위치가 바뀌는 숫자 키패드 또는 그림으로 된 화면 키보드 등)
      3. 유출을 100% 막기 힘드므로 OTP등 유출되어도 악용되기 힘든 시스템을 도입한다.
      4. 플러그인이 꼭 필요한 경우, 브라우저상에서만 작동하고 운영체제에 악영향을 끼치지 못하는 기술을 사용한다. (자바 애플릿이 언급되는 이유임)

      • http://hirameki.blogspot.com hirameki

        논지를 흐릴까봐 안쓰려고 했습니다만….
        윈도용 보안모듈은 MFC기술을 사용하는 모양입니다….. 휴….

  • youknowit

    “국가에서 안전하지 않다고 인정한 알고리즘”이라는 말씀은 저는 처음들어 봅니다. “실무자”가 아니라서 그렇겠지요 :)
    3DES는 공인전자서명기술규격이 SEED 와같은 수준의 안전도를 가지는 것으로 제시하고 있습니다.
    제가 “실무자”께 질문드리고 싶은것은 소프트포럼이 판매하는 보안접속 액티브액스는 SSL접속을 액티브액스로 구현하는 것입니다. 아시다시피 SSL 프로토콜의 보안취약점은 널리 드러나 있습니다. 현재 주요 웹브라우저들은 TLS접속을 기본으로채택하고 있습니다. 소프트포럼이사용하는 SSL 프로토콜의 버전이 무엇인지, 알려진 보안취약점 패치라도 한 모듈을 사용하고 있는지, 혹시 TLS 로 업그레이드할 계획은 없는지, 왜 지금껏 자신의 보안접속 액티브액스가 SSL접속을 위한것이라는 사실에 대하여 잠자코 있었는지, 그리고, “실무자”같은 분들이 나타나서 “SSL의 취약점 때문에 액티브액스를 써야한다”는 황당한 주장을 늘어놓으실때, 왜 소프트포럼은 자신들이 판매하는 액티브액스가 결국은 SSL 접속을 하고 있다는 사실을 한번도 고백하지 않았는지, 언제까지 이런식으로 장사를 할 것인지를 한번 물어봐 주시면 고맙겠습니다.

    “실무자”라는 분은 그 내막을 모르실지도 모르지만, 소프트포럼같은회사의 기술관계자들은 알고 있을 것 아니겠습니까? 많은 사람들이 장님 코끼리만지듯 SSL 취약하니, 액티브액스가 필요하니 왈가왈부할 때, 조용히 그 한심한 광경을 즐기고 계셨는지요?

  • youknowit

    “국가에서 안전하다고 인정하지 않은 대칭키 알고리즘”이군요.
    SEED 가 혹시 비대칭암호화 알고리즘이라고 상상하시는가요?
    하긴 전에 금감원 어떤분은 그렇게 생각하고 계시는듯도 했습니다만…..
    SEED 와 3DES 는 모두 대칭암호화에 사용되는 블록 사이퍼 입니다.

  • 전자정부이용자

    “실무자”가 사용자의 불편을 무시하고 자랑스럽게 발표한다니 놀랍습니다.
    MS마저도 보안에 쓰지말라는 ActiveX를 보안에 쓰는 것은 실무자의 편리를 위한 것입니다.

    다른 나라들 기를 어떻게 눌렀습니까? 외국도 한국의 ActiveX 인터넷 뱅킹과 HWP 문제를 알고 있습니다.
    고립된 인터넷 특수지역(갈라파고스)이 되면 당연 연구거리입니다.
    MS 윈도우 버젼도 “실무자편리”에 맞춰야 하고 Explorer 버젼도 “실무자편리”에 맞춰야 되니 관심거리 아닙니까?

    인터넷뱅킹때 매번 설치하는 ActiveX가 읽어가는 정보는 공개되지 않고 있습니다. ActiveX가 서버로 전송하는 정보를 공개해야 합니다.

    하루에도 매번 반복해서 설치하는 ActiveX가 있다면 그것은 패치를 위한 것이 아닙니다.
    사용자 PC의 정보(CPU ID, 맥어드레스, IP, 디스크 시리얼 정보, 브라우저버젼, OS버젼…)를 서버로 전송하고 나서
    ActiveX는 자신의 흔적을 지우고 유유히 사라지는 경우, 패치가 없어도 매번 새로 설치할 것입니다.
    실제 그렇다면 “키보드 보안”이 아니라 은행의 면피를 위한 사용자 PC에 대한 해킹이고 개인정보유출입니다.

    최근의 웹접근성(IE, 파이어폭스, 사파리) 향상에 “실무자”의 논리는 웹접근성 차단이고 웹표준 차단입니다.

    국내SW산업의 불균형이나 경쟁력 약화, MS종속 문제, 사용자들의 불편에 대해 어디에서 시작된 것인지 “실무자”도 생각하길 권합니다.

  • 바라미
  • 치즈

    실무자 사라졌네요… 대답해주시면좋을텐데 불리해지니까 사라진건아니겠죠 설마..

  • 샬라미

    실무자님 돌아와 주세요 그리워요~ 또 어떤 헛소리를 하실지~~

  • homeuser

    키보드후킹 등의 프로그램은 SSL과 같은 웹보안으로 막을 수 없습니다. ActiveX와 같은 OS보안 개념으로 막아야합니다. (Windows등에서 키보드 후킹 프로그램과 방어프로그램을 만들어 보신 분은 이해하실 듯 합니다.)

    논란거리는 제쳐둔다면, 현재 서비스 되는 키보드보안 ActiveX의 성능은 꽤 강력합니다.
    성공적으로 실행된다면 이미 바이러스로 떡칠된 MS PC에서도 성공적으로 키보드 후킹을 막아줍니다.
    성공적으로 실행되지 않을 경우엔 경고창을 보여주거나 아예 웹싸이트 접속을 막습니다.
    (물론 100%완벽하지는 않습니다. 대부분의 후킹 프로그램은 막아줍니다)

    앞에서 많은 분들이 말씀하신 것처럼, ActiveX 때문에 파블로프의 개처럼 사용자들이 악성 프로그램도 무심코 설치해버리는 폐해도 있고,
    리눅스나 아이폰처럼 상대적으로 보안이 강화되어 있는 OS에서 ActiveX때문에 서비스를 이용하지 못하는 단점도 생깁니다.

    하지만, 앞서 나온 JVM/https 등의 기술은 웹보안에 불과합니다. 화면, 마우스 캡쳐 뿐만이 아니라, 키보드 후킹을 막으려면 OS의 기능을 제한하거나 수정하지 않고서는 구현하는건 불가능합니다.
    (이는 스마트카드,OTP,PIN Code등의 이슈와는 또다른 문제입니다.)

    요약하면, 현재 뱅킹서비스 보안은 웹보안 뿐만이 아니라, OS보안의 문제이기도 하기때문에
    MS Windows에서라면 현재처럼 ActiveX로 OS의 기능을 수정/제한하는 방법이 가장 강력한 보안수단입니다.

    다른 OS에서도 현재 ActiveX와 같이, OS의 기능을 제한/수정해서 일정수준의 키보드 후킹 프로그램이 동작하지 않도록 하는 것이 제일 좋을듯 합니다.(이게 필요없는 OS도 물론 많습니다)

    장기적으로는
    - 각 OS별 보안솔루션을 개발하거나,
    - Windows PC에서는 보안모듈의 표준화/집단화로 설치되는 ActiveX 모듈 개수를 줄이거나
    - 전용 Browser를 통한 금융서비스를 제공해야합니다

  • http://openweb.or.kr youknowit

    homeuser/ 이미 여러번 이야기된 내용입니다만, 키보드보안 프로그램이 실행되는 동안에는 키값을 가로채기 어렵다는 점은 당연합니다. 그러나 다른 웹사이트에서 이용자가 입력하는 키값은 당연히 노출됩니다.

    문제는 다른 웹사이트에서 입력하는 암호가 공인인증서 암호와 같은 경우가 대부분이기 때문에 인증서+키보드보안을 아무리 강제해 본들 소용이 없습니다.

    그리고 보안카드는 어차피 OTP 성격입니다. 따라서 키입력값이 노출되어도 당장의 공격은 어렵습니다.

    님께서 말씀하신 수준의 내용은 이미 이해하는 분들이 대부분입니다.

  • homeuser

    >> 그리고 보안카드는 어차피 OTP 성격입니다. 따라서 키입력값이 노출되어도 당장의 공격은 어렵습니다.

    ^^;

    • T. K.

      homeuser님, 멋진 뒷북이었습니다. ㅋㅋ

  • Pingback: HTML 코딩 이야기 – #1 개념 확인 | 반토막 저장소