공인 인증 기술 웹 표준 기술 개발의 현황

이찬진 대표님이 제기하신 “공인 인증 기술 웹 표준 기술”에 대한 W3C 표준화 진행 사항 및 주요 논의점을 정리하였습니다.

먼저 읽어 볼 글: Web Crypto API의 현재와 미래
W3C 워킹 그룹: http://www.w3.org/2012/webcrypto/
국내 워킹 그룹: https://groups.google.com/forum/#!forum/webcrypto

공인인증서를 웹표준환경에서 다루기 위한 노력의 일환으로 W3C Working Group들에 참여하여 활동중인데요.
현재 공인인증서 관련 몇가지 접점을 가지고 있는 W3C 워킹그룹은 아래와 같고 해당 WG에서의 주요 이슈들을 짚어봅니다.

[Web Cryptography Working Group]
– 웹브라우저에서 암호기술을 자유롭게 다룰 수 있도록 하기 위한 취지로 시작되었고 브라우저 벤더로는 애플을 제외하고 모두 참여하고 있습니다.
– 현재 Low Level API는 거의 정의가 되었고 브라우저 벤더들이 구현에 들어가 있습니다.
– 공인인증서 관련해서 국내에서는 Web Crypto Korea라는 워킹그룹이 결성되어 PG, 정부기관, 공인인증기관 참여하고 있으며
– 작년에 SEED 알고리즘을 웹표준 도입을 제안하여 채택되었으며
– 올해초 Web Certificate API를 추가 제안하였습니다.
– WebCrypto WG에서 현재 주요한 이슈는 Same-Origin-Policy에 대한 것과 키 소유권에 대한 것으로 좁혀볼 수 있습니다.
– Same Origin Policy는 생성된 키는 도메인에 바인딩되어 있어서 해당 키에 대해 접근하기 위해서는 키를 생성했던 동일 도메인에 접속해야합니다.
– 공인인증서 케이스를 투영해보면 공인인증서를 발급받은 해당 웹사이트에서만 Private Key를 호출하여 전자서명등을 생성할 수 있게 됩니다.
– 국내에서는 이에 대한 예외처리를 주장하고 있고 만일 예외처리 주장이 받아들여지지 않는다면 공인전자서명 생성을 위해서는 인증서를 발급해준 공인인증기관의 웹사이트로 와야합니다.
– 몇가지 UseCase들은 이부분을 iframe이나 OAuth, SAML등의 방식으로 해결시도를 하고 있습니다.
– 키 소유권 문제는 미국쪽 브라우저 벤더들은 키소유권이 Key Provisioner에게 있다는 개념이고 즉 키 생성을 구글 웹사이트에서 했다면 해당 키에 대한 소유권이 구글에게 있다는 주장을 하고 있으며 한국, 유럽쪽 멤버들은 키소유권이 유저에게 있다고 주장합니다.
– 키 소유권 문제는 USB 보안토큰부분과도 밀접한 상관관계를 가지고 있고 아직 미해결 상태입니다.
– 현재까지의 Spec으로 보면 생성된 키는 Web Storage(Session Storage, Local Storage, Index DB)중 IndexDB에 담길 가능성이 큽니다.

[Web Application Security Working Group]
– 여기에서는 HTML5시대로 넘어오면서 Javascript이 예전과 달리 다양한 기능을 포함하게 되면어 JS 무결성등 Browser Sandbox내의 Operation을 어떻게 보호할것인가에 대해서 집중하고 있으며 주요한 결과물로는 CORS(Cross-Orogin Resource Sharing)등이 있습니다.
– 그외에 현재 논의를 집중하고 있는 영역은 CSP (Content Security Policy)이고 JS무결성등의 보호방식을 이야기하고 있습니다.
– 여기에도 철학적인 개념이 개입됩니다.
– 이용자 PC가 침해되었을 때는 어떠한 보안조치도 무의미하다는 보안인식을 해외 멤버들은 철저하게 유지하고 있고
– 국내에서는 이용자 PC의 침해가능성에 대비한 다양한 보안대책들을 추가하고 있는것과는 조금 방향이 다릅니다.
– 다행히 Browser Sandbox로 로딩되는 JS 무결성을 서버에서 보장할 수 있는 몇가지 구체적인 논의들이 진행중이라서 (JS에 대한 hash검증, 서명검증, nonce 검증 등) 국내에서도 써먹을 가능성이 있습니다.
– 이 WG 의장사는 PayPal이고 결제서비스를 하면서 접하는 문제 해결을 위해서 적극적으로 참여하고 있습니다.

[System Application Working Group]
– 여기에서는 System Level의 Resource들 (문자메세지, 경고체계(알람, 진동 등))에 대한 접근을 웹에서 할 수 있도록 표준화를 진행중이고요 삼성이 의장사를 맡고 있습니다.
– 타이젠 OS의 차별성을 위해서 노력하는 모습이 보이고요
– 얼마전에 GemAlto사에서 Secure Element API를 제안하였고 이것은 사실상 USB 보안 토큰에 접근하기 위한 웹표준을 정의하자는 내용입니다.
– WebCrypto WG내의 멤버들이 다수 여기에도 참여하여 의견을 주고받고 있는 상태이고
– Secure Element API가 채택된다면 USB 보안토큰을 공인인증서의 저장소로 활용할 가능성이 생깁니다.

이동산 이사님께서 잘 설명해 주셨는데, Same Origin Policy(SOP)와 키 소유권 문제에 대해 약간 부연설명을 해야 할듯요. SOP는 키 소유권 문제라기 보다는 키 보안에 관련된 사항이라고 볼 수 있습니다.

만약 CA로 부터 발급 받은 개인키를 여러 웹 사이트에 동시 사용 가능하다면 키가 노출이 됐을때, 해킹 비용이 감소 될 수 밖에 없습니다. 따라서 발급된 개인 키를 단일 도메인 웹 사이트에서만 사용하는 것은 해킹 비용을 증가시키기 때문에 중요한 원칙입니다.

사실상 현재 한국 공인 인증 시스템의 개인 키 사용 방법은 원래 웹 기반 CA 시스템이 만들어질 때 개념을 오용한 것으로 볼 수 있습니다.

과거 웹 기반 CA 시스템은 SSL 기반의 인증 계층 체계로 되어 있고, 서버 키로 생성된 개인 키를 가지고 서명과 검증을 하게 되어 있었죠. 따라서, CA로 부터 받은 서버키로 개인키를 만들기 때문에 서명을 해도 서버키가 검증을 하는 체계였기 때문에 SOP를 적용하더라도 큰 문제는 없죠.

하지만, 한국의 공인 인증 체계는 개인키를 인증 기관이 발급을 하고 있고, 단일 저장소에서 똑같은 개인키를 함께 쓰기 때문에 문제가 발생하는 것 아니겠습니까? 게다가, 다른 은행에서 범용 공인 인증서를 쓰려면 등록이라는 절차를 또 거쳐야 합니다. 사용자 입장에서는 새로운 키 발급이나 등록이나 똑같다고 볼 수 있죠. 사실상 이동성에 대한 편리함 밖에 없죠.

SOP는 거의 표준적인 보안 원칙이기 때문에 (예외를 주장하더라도) 인정되기 어렵다고 생각됩니다. 따라서, 이를 인정하고 국내 공인 인증 시스템도 보안과 편의성이 동시에 담보되면서 비지니스가 배가 될 수 있는 방식으로 진화되어야 한다고 봅니다. 결국 기술 문제라기 보다는 정책 문제죠.

(1) 비범용 인증서: 각 은행이나 보험사에서 그 사이트에서만 사용하는 인증서입니다. (무료입니다.) 현재 GPKI와 KISA ROOTCA들이 서버키를 발급을 하고 있는 추세이기 때문에 개인키를 서버에서 발급하고, 서명 검증을 하는 것도 한 방법이라고 봅니다.
(2) 범용 인증서: 각 은행이나 카드사 등에 여러번 등록해서 함께 쓸 수 있는 개인 인증서죠. (연 4,000원) 이건 그냥 인증 기관들이 발급을 하고, 트랜잭션도 등 인증기관이 책임지도록 하면 될 것 입니다. 돈 받는 데 그정도 서비스는 해 줘야죠.

제 개인적으로 봐도 주거래 은행도 1~2개고, 카드도 1~2개고 더 이상 로그인 정도 하는데 범용 공인 인증서를 강제하지만 않는다면, SOP를 기반한 비범용 인증서 쓰는것도 문제가 안될 것 같네요.

범용 인증서를 발급할 게 아니라 공인 인증 기관들이 비범용 인증서간 호환 서비스를 해주면서, 트랜잭션에 돈을 받는게 더 돈을 벌 수 있을 거라 생각도 들구요. (예를 들어, 국민은행에서 발급받은 비범용인증서를 신한은행에서 발급받기 쉽도록 인증 호환 서비스해 주고, 한 500원 받으면 소수의 다량 인증서 사용자들이 돈을 더 내고, 다수의 소량 인증서 사용자들이 돈을 덜 내는 구조가 될 수도 있구요.)

결론은 새로 웹 기반 인증 시스템이 표준화 되는 마당에 국내 공인 인증 업체들이 과거 방식을 선호할 게 아니라 앞으로 더 비지니스가 되는 방식을 연구해야 된다고 봅니다.

p.s. 추가로 정부 기관에서 단순 본인 확인하고 로그인 정도 하는데 인증서 쓰지 말게 합시다. 인증서 남용의 원인입니다.

여러분의 생각

의견 쓰기

이름* 이메일* 홈페이지(선택)