공인인증서, 애플리케이션 접근성

in #kr7 years ago

국내에 공인인증서가 생긴 배경과 위험성


공인인증서란 쉽게 말해 전자 인감도장이다. 우리나라에는 '이 도장이 내 도장이다'고 관공서를 통해 정식으로 인증받는 '인감(印鑑)'이라는 독특한 제도가 있다. 공인인증서는 이 인감을 웹으로 옮겨둔 제도다. 사용자가 인터넷 상에서 한 거래를 '이 거래는 내가 승인한 거래다'고 인증해주는 기술이다.
공인인증서 역시 초창기 열악한 인터넷 환경에서 어떻게든 인터넷뱅킹과 전자상거래를 구현하기 위해 고안해낸 기술이다. 플러그인과 비슷하다.
초기 웹 브라우저는 암호화 능력이 부족해 해커가 중간에서 데이터를 가로채기 쉬웠다. 암호화 전송기술 자체가 없는 것은 아니었다. 넷스케이프 그룹이 95년 고안해낸 SSL(Secure Sockets Layer, https)라는 기술이 암호화 전송기술 표준으로 각광받았다. 하지만 미국 정부의 방침 탓에 인터넷뱅킹을 구현하기엔 암호화 수준이 모자랐다. 때문에 독자적인 암호화 기술을 적용한 공인인증서를 개발해냈다. 그리고 플러그인을 사용해 공인인증서를 웹 브라우저에 적용하기 시작했다. 공인인증서와 액티브X의 밀월관계는 이렇게 시작됐다.
인터넷뱅킹을 구현하려면 3가지 요소가 필요하다.

1. 암호화 전송기술이다. 사용자와 은행이 주고받는 데이터를 암호화해 크래커가 데이터를 분석할 수 없게 하는 것이다.
2. 사용자 인증이다. 사용자 또는 은행이 본인이 맞음을 인증해 크래커가 사용자나 은행으로 가장해 데이터를 탈취할 수 없게 하는 것이다.
3. OTP(일회용 암호)다. 거래만을 위한 전용 비밀번호를 생성해 해킹을 방지한다. 공인인증서는 여기서 첫 번째와 두 번째를 구현하기 위한 기술이다.


외국의 경우 암호화 전송기술은 SSL로 해결했다. 분명 초창기 공인인증서는 SSL보다 안전했다. 하지만 지금은 둘의 차이가 없다. SSL은 TLS(Transport Layer Security)로 이름을 바꾸고, AES 56비트 암호화를 거쳐 128비트, 256비트로 암호화 수준을 점점 강화했다. 공인인증서도 비슷한 절차를 밟았다. AES 128비트 암호화를 거쳐 2012년 초 256비트로 강화됐다.

사용자 인증은 어떻게 해결했을까. 외국과 국내는 이 부분이 좀 다르게 진행된다. 국내에서 인터넷뱅킹을 하려면 사용자가 본인 인증을 받아야 한다. 미래창조과학부가 지정한 금융결제원, 한국정보인증, 코스콤, 한국전자인증, 한국무역정보통신 등 5곳의 공인인증기관이 사용자가 본인이 맞음을 인증해준다. 이 과정을 통해 발급받은 것이 바로 공인인증서다.

반면 외국의 경우 사용자는 본인 인증을 받을 필요가 없다. (인터넷뱅킹에 본인 인증을 요구하는 일부 국가가 존재하긴 한다). 은행만 인증을 받으면 된다. 그렇다면 은행은 누가 인증해줄까? 국내와 다르게 국가가 아닌 공신력있는 제3자가 인증해주는 방식을 취하고 있다. 베리사인, 코모도 그룹 등이 대표적인 제3자 인증기관이다. 이러한 제3자 인증기관에서 발급한 인증서를 'EV SSL 인증서'라고 한다. SSL로 암호화된 홈페이지(URL 앞부분에 https라고 적혀 있는 홈페이지)에 접속하면, EV SSL 인증서를 통해 '누가 이 홈페이지를 인증해줬고 어느 정도로 암호화돼 있는지' 웹 브라우저를 통해 손쉽게 확인할 수 있다. 웹 표준 기술이기 때문이다.

여기서 문제가 발생했다. 국내의 경우 사용자가 본인 인증을 받다보니 은행은 손쉽게 해커유무를 판독할 수 있지만, 사용자는 은행 홈페이지가 진짜인지 피싱 사이트(진짜 홈페이지인것처럼 위장한 해킹 사이트)인지 구분하기 힘들다. 2000년대말 온갖 피싱 사이트가 기승을 부린 이유다. 결국 문제를 깨달은 국내 은행들은 국민은행을 필두로 하나둘씩 자사 홈페이지를 제3자 인증받았다. 공인인증서의 본인 인증방식에 문제가 있음을 스스로 시인한 셈이다.

사실 더 큰 문제는 따로 있다. 공인인증서가 보안이라는 원래의 목적에서 벗어나 금융기관의 책임 면피용으로 사용되고 있다는 점이다. 여기선 고려대학교 법학전문대학원 김기창 교수의 발언을 인용한다.

"공인인증서는 정부가 금융기관에게 준 면죄부입니다. 나(금융기관)는 이만큼 보안에 노력을 기울였으니 금융사고가 발생해도 사용자에게 책임을 지지 않는다는 보증서죠. 예를 들어봅시다. 해커가 사용자의 계정과 공인인증서를 탈취해 외국에서 인터넷뱅킹을 시도했습니다. 은행은 단번에 이 사실을 알 수 있죠. 평소에 사용자가 접속하던 국내 IP가 아니라 해외 IP이니까요. 외국 은행같으면 의심스럽기 때문에 이 거래를 거절하고, 즉시 사용자에게 연락을 취할겁니다. 그런데 국내 은행은 그냥 승인합니다. 인증된 사용자(공인인증서)가 거래를 한 것이니 거절할 이유가 없다는 겁니다. 이 때문에 은행의 관리책임을 물어 사용자에게 배상하라는 법원 판결 자체가 나오질 않습니다. 공인인증서가 인감도장과 같은 역할을 하니, 해커가 한 거래조차 사용자가 한 거래로 인식할 합당한 이유가 은행에게 있다는 겁니다. 과거 오프라인상에서나 통할 법할 논리를 21세기 온라인상에서 펼치고 있어요. 이렇게 정부가 면죄부를 발행해주니 은행들은 보안을 강화할 필요성 자체를 느끼지 못하게 됩니다."

국내의 경우 은행 ID/비밀번호, 공인인증서, OTP라는 삼중 보안을 취하고 있다. 반면 해외의 경우 은행 ID/비밀번호, OTP라는 이중 보안을 기본으로 한다. 얼핏 보면 국내가 훨씬 안전할 것 같지만, 실상은 그렇지 않다. 외국 은행의 경우 ID/비밀번호, OTP 외에 참신하면서도 강력한 보안방법을 개발해 자체 적용하고 있다. 뱅크오브아메리카(BOA)의 예를 들어보자. BOA 홈페이지에서 인터넷뱅킹을 하려면 은행 ID/비밀번호, OTP 외에 이미지 패스워드라는 독특한 과정을 하나 더 거쳐야 한다. 사용자만 알 수 있는 암호화된 그림을 보여줘 해당 그림을 찾지 못하면 거래를 진행할 수 없다. 제3자인 해커는 이 이미지 패스워드 과정을 뚫기 힘들다. 외국 은행 대부분이 이렇게 자체 개발한 보안 방식을 적용해 삼중, 사중 보안을 취하고 있다. 반면 국내 은행은 정부가 지정해준 공인인증서에만 보안을 기대고 있다.

공인인증서에 적용된 암호화 기술 'SEED'는 W3C가 인증한 웹 표준 기술이 아니기 때문에 웹 브라우저 적용하려면 반드시 플러그인이 필요하다. 대안인 HTML5도 원래 액티브X, NPAPI 대체보다 플래시, 실버라이트 같은 액션 스크립트 대체를 목적으로 개발된 기술이다. 웹 표준인 SSL과 EV SSL 인증서가 아닌 다른 보안방식을 쓰려면 결국 HTML5에 확장 기능을 추가해야 한다. 달라지는 게 하나도 없다. 사용자는 여전히 웹 브라우저에 무엇인가를 덕지덕지 설치해야 하고, 은행은 여전히 공인인증서만 철석같이 믿고 있겠다. 외국인은 여전히 국내 쇼핑몰을 이용할 수 없다.

애플리케이션 접근성


1. 앱(애플리케이션) 접근성?

"모바일 애플리케이션 접근성"이란 모바일 기기를 사용하여 모바일 애플리케이션을 이용하고자 하는 장애인, 고령자 등이 비장애인과 동등하게 모바일 기기를 사용하여 애플리케이션을 이용할 수 있도록 보장하는 것’ 을 말한다.

2. 앱(애플리케이션) 접근성의 현 상황

2016년 10월 20일 미래창조과학부와 국립전파연구원은 장애인과 고령층 등이 스마트폰 앱을 편리하게 이용할 수 있는 환경을 마련하기 위해 ‘모바일 애플리케이션 콘텐츠 접근성 지침 2.0’을 국가표준으로 제정했다.

이는 장애인·고령층 등 정보취약계층이 일반인과 동등하게 모바일 앱 콘텐츠를 편리하게 이용할 수 있도록 모바일 앱을 제작할 때 준수해야 할 지침으로, 스마트폰이나 태블릿 기기 등 모바일 기기에 적용된다.

이번에 제정된 국가표준에는 모바일 앱 개발시 준수해야 할 인식의 용이성, 운용의 용이성, 이해의 용이성, 견고성 등 4가지 원칙과 이 원칙을 달성하기 위한 18개의 세부 지침으로 구성돼 있다.

스마트폰 등 모바일 기기가 대중화됨에 따라 장애인, 고령자등이 인터넷이나 앱 상의 콘텐츠를 쉽게 이해하고 정보접근성을 제고 할 수 있도록 구체적인 기준을 국가표준으로 제정했다. 시각장애인이 모바일기기의 음성읽기 기능을 이용해 정보를 들을 수 있도록 버튼, 메뉴 이미지 등에 대체 텍스트를 제공하고, 모든 메뉴를 순차적으로 읽어줄 수 있는 기능을 구현하도록 하고 있다.