본문 바로가기

Home > 열린마당 > 공개SW 소식

공개SW 소식

공인인증서 강제 사용, 왜 불합리한가

OSS 게시글 작성 시각 2013-07-09 11:09:57 게시글 조회수 3895

2013년 07월 08일 (월)

ⓒ 블로터닷넷, 이지영 기자 izziene@bloter.net



맥 OS X, 크롬 웹브라우저를 주로 쓰는 사람으로서, 공인인증서를 도무지 이쁘게 봐줄 수 없다. ‘지원하지 않는 브라우저입니다’,  ’지원하지 않는 운영체제입니다’, ‘본 연결은 신뢰할 수 없음’ 등과 같은 경고 문구 앞에 수차례 결제 거래가 좌절된 경험 탓이다. 연말정산할 때, 인터넷에서 D모 피자를 주문할 때 공인인증서 실행을 위한 플러그인을 설치하지 못해 윈도우 PC를 켜거나 스마트폰으로 배달 주문을 해야 했다.


왜 우리는 웹사이트에 아이디와 비밀번호를 입력하고 신용카드 결제 번호를 넣어 인터넷 거래를 하면 안되는 걸까. 강아지 백내장 치료를 위해 해외 웹사이트에서 안약을 구매할 때 요란한 팝업창 없이도 구매를 마쳤는데. 물건도 문제없이 잘 받았고.


그렇다. 나는 공인인증서 외에 다른 인증 방식 도입도 필요하다고 보는 전자금융거래법 개정 법률안에 찬성한다. 맘 편하게 비 윈도우, 비 인터넷 익스플로러 환경에서 금융결제 서비스를 누리고 싶다. 그러려면 넘어야 할 산이 많다. 지난 6월 법안심사소위에 상정된 전자금융거래법 개정안은 계류됐다. 10월 국회가 열릴 때 다시 논의될 예정이라고 하지만, 최근 분위기를 보면 이 법안은 통과되기 쉽지 않을 전망이다. “공인인증서는 13년간 잘 운영되고 발전되어 왔다. 갑작스런 폐지는 사용자 혼란을 부추길 것”이라거나 “우리나라 공인인증서는 이미 안정성을 보장 받았다”는 식의 주장 때문이다.


전자금융거래법 개정안이나 전자서명법 같은 복잡한 법률은 잠시 뒤로 하고 공인인증서 그 자체만을 바라보자. 지금 우리가 사용하고 있는 공인인증서는 정말 안전한 거래를 보장하고 있는가.


opennet
▲지난 5월23일 국회에서 열린 전자서명법, 전자금융거래법 개정법률안 공청회

국제 표준 따르지 않는 공인인증서

공인인증서 안정성을 이해하려면 인터넷 거래에서 인증서가 어떻게 쓰이는지부터 이해할 필요가 있다. 인증서는 정보를 암호화하는 ‘자물쇠’ 역할과 암호화된 정보를 확인하는 ‘열쇠’ 역할을 동시에 한다. 이 과정에서 자물쇠 기능은 SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security) 기술을 사용한다. SSL과 TLS는 공개된 암호화 방식인 공개키와 자신만 알 수 해독할 수 있는 개인키를 활용해 사용자가 인터넷을 통해 안전하게 정보를 주고받을 수 있게 도와준다.


웹사이트는 ‘나는 믿고 신뢰할 수 있는 웹사이트입니다’라는 사실을 알리기 위해 인증기관으로부터 인증서를 발급받는다. 이를 위해 인증기관에 자신의 정보와 공개키를 제출한다. 인증기관은 검증을 거친 후 웹사이트 정보와 공개키를 인증기관의 개인키로 암호화한다. 이를 웹사이트 인증서라고 부른다. 사용자는 이 웹사이트 인증서를 웹브라우저를 통해 확인한다. 모든 웹브라우저에는 웹사이트 인증서를 해독할 수 있는 기능이 담겨 있다. 해독 후 인증서가 확인되면 웹브라우저는 서로 신뢰할 수 있는 웹사이트라고 판단해 보안된 통신을 주고 받는다. 이러한 방식을 공개키 기반구조(PKI)라고 부른다. 우리나라 역시 PKI기반 ‘공인인증서’를 사용한다.


문제는 우리나라 공인인증서를 통해 정보를 주고 받으려면, 이를 위한 별도의 프로그램을 설치해야 한다는 점에 있다. 웹브라우저는 한국 공인인증서를 이용한 보안 통신 기능을 제공하지 않는다. 공인인증서 사용을 위해 인터넷 익스플로러에서 ‘액티브X’를 띄워야 하는 이유다. 물론 이 때 액티브X를 통해 내려받는 보안 프로그램이 정말 보안 프로그램인지 확인할 수 있는 방법은 없다. 어쨌거나 사용자는 ‘예’를 눌러야만 웹사이트에 접속할 수 있기에 ‘안전하다’라고 믿고 보안 프로그램을 내려받는다. 웹사이트가 탈취돼 악성코드 등 불법 소프트웨어를 내려받을 가능성은 무시된다.

서버 인증보다 사용자 인증이 우선

표준 보안 방식은 플러그인을 필요로 하지 않기 때문에 서버에서 인증서를 확인하고 사용자를 인증하는 과정을 거친다. 그러나 공인인증서는 사용자 인증을 우선한다. 플러그인을 설치하는 과정에서 서버 인증 절차를 건너뛰기 때문이다.


서버 인증은 사용자가 방문하려는 웹사이트에서 스스로 ‘나는 안전한 곳입니다’라는 인증서를 보여주는 과정이다. 사용자는 해당 인증서를 보고 안심하면서 웹사이트에 방문한다. 사용자 인증은 사용자 스스로 ‘나는 안전한 사람입니다’를 증명해야 웹사이트에 방문할 수 있는 방식이다. 똑같은 웹사이트를 방문해도 서버 인증은 방문지 보안을, 사용자 인증은 사용자 보안을 챙긴다.


공인인증서는 방문하려는 사용자 보안을 챙긴다. 국가기관에 들어가려면 입구에서부터 각종 검문 수색을 당하는 것과 같다. 정작 내가 들어가고자 하는 국가기관이 진짜 국가기관인지는 확신할 수 없다. 국가기관 건물로 가장한 건물에 들어가 오히려 낭패를 볼 수 있단 얘기다. 결국 공인인증서는 불편하면 불편했지 더 나은 보안을 보장해주진 않는다.

개인 PC 속 폴더에 개인키 저장하는 공인인증서

우리나라 공인인증서는 별도의 플러그인을 사용해야만 내려받을 수 있다. 이 때 인증서는 ‘NPKI’나 ‘UserProfile’처럼 우리가 흔히 볼 수 있는 일반 폴더에 저장된다. 웬만큼 컴퓨터를 쓰는 사람이라면 누구나 ‘복사하기’ 기능을 통해 얼마든지 인증서를 빼낼 수 있다. 이렇게 빼낸 인증서에 비밀번호를 대입하면, 누구나 남의 인증서를 쓸 수 있다는 얘기다.


물론 현재 공인인증서에 적용된 암호 알고리즘은 모두 국제표준인 공개키 알고리즘인 RSA알고리즘(2048bit), 해쉬 알고리즘인 SHA2(256bit), 개인키 암호화 알고리즘인 SEED(128bit)를 사용하고 있다. 하지만 모두 사용자가 공인인증서를 내려받을 때 입력한 ‘비밀번호’를 암호화한 것에 불과하다. 만약 훔친이가 또 다른 해킹 도구를 사용해 비밀번호까지 알아낸 상태라면, 무단 계좌이체와 같은 금융 피해가 발생할 수 있다.


인터넷 익스플로러, 파이어폭스, 크롬, 사파리, 오페라와 같은 주요 웹브라우저가 지원하는 표준보안방식은 인증서 발급과정이 다르다. 공인인증서와 마찬가지로 인증서를 내려받는 점에선 같지만, 저장 과정에 차이가 있다.


표준보안방식은 각 웹브라우저나 운영체제가 지원하는 암호화 방식을 활용해 인증서를 PC에 저장한다. 윈도우는 ‘Crypto Keystore’, 맥은 ‘Keychain’, 리눅스는 ‘Gnome keyring’, 안드로이드는 ‘Credential storage’ 방식을 사용한다. 이 과정에서 플러그인을 따로 내려받을 필요는 없다.


웹브라우저나 운영체제가 지원하는 암호화 방식을 활용해 저장하기 때문에, 사용자가 따로 인증서 비밀번호를 넣을 필요가 없다. 사용자도 모르는 암호로 인증서가 저장되므로, 해커가 몰래 키보드 해킹 프로그램을 사용자 PC에 깔아두고 사용자가 비밀번호를 입력하는 순간 빼내는 일이 애당초 불가능하다. 게다가 각 운영체제는 암호화 방식을 수시로 바꾸기 때문에 해커가 침입해 인증서를 복사해 간다고 해도 비밀번호를 알아내기가 쉽지 않다.


표준보안방식은 공인인증서와 달리 인증서를 복사해 사용하기도 쉽지 않다. 사용자 PC에 설치된 운영체제가 자동으로 생성하는 암호로 보호된 덕에 인증서가 복사돼 이동하는 순간 무용지물이 된다.


표준보안방식에서 인증서를 복사하려면 웹브라우저의 ‘인증서 내보내기’ 기능을 써야 한다. 그 과정에서 사용자는 인증서를 내보내기 위한 비밀번호를 입력한다. 이 비밀번호를 입력해야만 다른 운영체제에서 발급받은 인증서를 내려받아 사용할 수 있다.


누구나 복사해서 비밀번호를 찾을 확률이 높은 공인인증서와 복사하기조차 쉽지 않은 인증서 중 어떤 인증서가 위협에 노출될 가능성이 높을까. 답은 뻔하다. 안전한 금융거래를 위해 공인인증서 강제가 꼭 필요한지 생각해볼 때다.




※ 본 내용은 (주)블로터 앤 미디어(http://www.bloter.net)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒ 블로터 앤 미디어. 무단전재 및 재배포 금지



[원문출처 : http://www.bloter.net/archives/157779]

맨 위로
맨 위로