기고 | 공인인증서 문제와 PKI, 그리고 안전한 공인인증 기술

ITWorld

우리나라의 공인인증서는 많은 질타를 받아왔고 이제는 사라질 위기를 맞고 있다. 이번 기고에서는 먼저 공인인증서의 원천적인 문제점이 무엇인지, 그리고 개인용 PKI가 주는 장점들, 그리고 마지막으로 안전한 공인인증 기술에 대해 알아본다.

공인인증서의 문제점
사실 공인인증서의 문제점은 공인인증서의 배포 당시 윈도우 운영체제의 다양한 취약점, 그리고 스마트카드 리더(reader)의 사용에 대해 반대했던 금융권의 설계 원칙에서부터 시작됐다. 공인인증서의 문제점은 대체로 암호학적 문제, 액티브X 문제, 운영체제 문제, 보안 3종 세트 문제, 그리고 UI, UX의 문제점 등이 다양한 측면에서 산재되어 있는데, 이를 하나씩 살펴보도록 하자.

- 암호학적 문제점: 설계부터 잘못된 시스템
대부분의 정보보호 교과서에서는 비밀키는 안전하게 저장돼야 한다고 이야기를 하고 그 방법으로 하드웨어에 저장하며 비밀키를 이용한 연산은 하드웨어 내부에서 일어나야 한다고 설파한다.

교과서의 이런 가르침과 달리 우리나라의 공인인증서는 처음부터 NPKI 디렉토리에 사용자의 비밀키로 암호화되어 저장되어 왔다. 이런 설계로 인해 공인인증서의 안전성은 전적으로 메모리 해킹의 가능성 여부와 비밀번호의 안전성에 의존하게 됐으며, 공개키의 안전성과는 동떨어지게 됐다. 즉, 국내 공인인증서는 암호학적으로 처음부터 잘못 설계된 시스템이다.

- 액티브X 문제점: 사용자 UX의 관성
액티브X(ActiveX) 또한 설계 초기부터 많은 논란을 가져왔었고 지금도 논란 속에 있다. 이런 논란의 핵심은 크게 두 가지로 나눠 볼 수 있다.

먼저 액티브X 자체의 취약점이다. 액티브X의 취약점이 있을 경우 공인인증서의 비밀키가 노출될 위험이 있다고 주장한다. 하지만 필자는 액티브X의 가장 큰 문제점은 UI와 UX에 있다고 생각한다.

즉, 모든 사용자가 서드파티 애플리케이션 프로그램을 설치하겠냐는 질문을 윈도우 운영체제에서 물어볼 때 확인을 누르는 '관성'이 생긴다는 점이다. 끊임없이 새로운 소프트웨어를 깔라고 강요하고 새로운 사이트에 들어갈 때마다 새로운 소프트웨어들을 설치하라고 강요함으로써 사용자들은 '확인' 버튼을 누르는 것을 매우 자연스럽게 생각하게 되었다.

즉, 하나의 소프트웨어를 다양한 애플리케이션에 적용할 수 있지 않고 모든 애플리케이션마다 다른 소프트웨어를 깔아야 하는 것이 문제의 핵심이라고 생각한다. 이런 소프트웨어의 숫자가 늘어나면 취약점은 늘어날 수 밖에 없고 취약점이 늘어나면 다양한 공격 또한 가능하다.

- 운영체제의 문제점: 윈도우와 안드로이드 자체의 많은 취약점
공인인증서 개발 초기부터 가장 많이 사용되어 왔던 윈도우, 그리고 최근에 점차 사용이 늘어가고 있는 안드로이드, 이 두 운영체제는 많은 취약점을 노출해 왔다.

먼저 안드로이드는 루팅(rooting)을 허용해야 하는 시스템이다. 또한 웹키트(webkit), 브라우저 등 다양한 취약점이 계속 존재해 왔고 ASRL(address space layout randomization) 또한 최근에 도입이 됐지만 여전히 취약점은 존재하고 있다.

뿐만 아니라 안드로이드 운영체제 위에 개발되는 애플리케이션들의 취약점은 이런 문제를 악화시키고 있다. 윈도우는 최근 보안이 과거에 비해 많이 강화됐지만 여전히 새로운 운영체제의 도입이 지연되고 있으며, 특히 우리나라의 다양한 공인인증용 소프트웨어는 보안성을 약화하라고 강요하고 있다.

여기에 앞에서 언급한 액티브X의 취약점, 그리고 그 기반 위에 개발되는 공인인증용 소프트웨어의 취약점들은 다양한 개발 과정 상에서 완벽한 구현을 요구하고 있다.

따라서 현재 운영체제의 안전성에 근간을 둔 공인인증용 소프트웨어 개발은 원천적인 문제를 갖고 있다. 마지막으로 루팅이 될 경우 최근 이슈가 되고 있는 메모리 해킹, 그리고 키보드 로깅 등은 전문적 해커에게는 어려운 기술이 아니다.

- 보안 3종 세트의 문제점
이렇게 취약한 운영체제의 문제점을 보완하기 위해 국내 보안업체들은 이른바 보안 3종 세트를 내세웠다. 보안 3종 세트는 키보드해킹방지 플러그인, 개인방화벽, 바이러스스캔 플러그인으로 구성된다.

먼저 키보드 해킹방지 플러그인은 이미 게임업계에도 도입됐으나 게임을 좋아하는 학생들 사이에서 이를 우회하는 방법은 매우 쉬운 것으로 알려져 있다. 또한 운영체제 루팅 시 큰 도움을 주지 못한다.

또한 바이러스스캔의 경우 잘 알려져 있듯이 이미 공개된, 그리고 시그니처가 존재하는 공격에만 적용이 가능하다. 따라서 패치가 존재하지 않는 제로데이 취약점에 대해서는 아무 기능을 할 수 없다.

엄청나게 많은 액티브X 소프트웨어가 나오는 상황에서 각각에 대해 제로데이 취약점이 존재하는 것을 방지하는 것은 불가능한 상황이다.

즉, 바이러스 스캐너는 공인인증서의 관점에서는 사후약방문이 될 수 밖에 없는 솔루션이다. 개인방화벽 또한 마찬가지다. 교과서에 나와 있듯이 의태(mimicry) 공격, 즉, 많이 사용되는 포트에 많이 사용되는 트래픽과 유사하게 통신할 경우 쉽게 우회할 수 있다.

뿐만 아니라 다양한 액티브X 소프트웨어에 다양한 3종 세트를 설치하다 보니 앞서 언급한 UX 문제를 악화시키는 결과를 낳고 있다. 또한 운영체제 루팅 시 이런 솔루션들은 큰 도움을 주지 못한다.

- 다른 UX, UI 문제들: 사용 불편, 책임 전가
국내 공인인증용 소프트웨어들은 사용하기가 매우 불편하다. 많은 경고문들은 사고가 터졌을때 모두 사용자의 문제인양 설명하고 있으며, 쓸데없이 많은 클릭 유도와 입력을 강요하고 있다. UX의 개선이 없을 경우 안전해지기 위해서는 불편할 수 밖에 없다는 보안에 대한 나쁜 인상을 줄 수 밖에 없다.

요약하건대, 국내 공인인증용 소프트웨어들은 불편하면서도 안전하지 않다. 안전성의 문제는 이론, 구현, UX 등 다양한 부분에 존재하며 새로운 구현이 필요한 시점이다.


그럼에도 공인인증서는 필요하다
이런 다양한 취약점에도 불구하고 필자는 공인인증서, 혹은 PKI(Public Key Infrastructure) 관점에서 개인용 인증서는 꼭 필요한 기술이며, 우리의 보안을 향상시키며 우리네 삶을 편안하게 할 수 있는 핵심기술이라고 단언한다.

공인인증서 혹은 PKI 관점에서의 개인용 인증서와 다양한 대체 기술을 비교, 설명해본다.

- 공인인증서 vs. 비밀번호 + SSL
공인인증서와 비밀번호+SSL. 이런 비교는 많은 사람들이 해 왔다.

그간 비교 설명을 한 대부분의 문서는 안전하지 않은 공인인증서 구현과 비교적 안전한 비밀번호+SSL의 구현을 비교했기 때문에 공정하지 않았다고 생각한다.

따라서 안전하고 편리한 공인인증서의 구현과 안전하고 편리한 비밀번호+SSL의 구현을 비교하고자 한다.

비밀번호 기반의 시스템들은 먼저 사용자가 복잡한 많은 비밀번호를 기억해야 하는 어려움이 있다. 대부분의 사람들은 이 부분을 귀챦게 생각하고 비밀번호를 컴퓨터에 저장하거나 같은 비밀번호를 다양한 시스템에 쓴다는 사실은 매우 잘 알려져 있다.

우리나라와 같이 웹서비스가 취약한 나라에서 비밀번호의 노출은 매우 빈번하게 일어나고 있으며, 이와 같은 동일 비밀번호를 다양한 웹사이트에서 사용하는 것은 매우 위험하다.

암호화나 해시가 된 비밀번호가 노출이 된다고 하더라도 우리나라의 경우 레인보우 테이블(Rainbow table) 등을 이용해 비밀번호를 복구하는 것은 어렵지 않다. 또한 비밀번호 기반 시스템들은 그 특성상 온라인/오프라인 사전 공격(dictionary attack)에 취약하다.

마지막으로 비밀번호 기반 시스템들은 루팅이 될 경우 키로깅(keylogging)에 의해 비밀번호가 쉽게 노출될 수 있다.

이와 달리 비밀키를 안전하게 저장하고 사용할 수 있는 공인인증서를 구현할 경우 공개키 암호 알고리즘에 안전성을 담보할 수 있다. 사전 공격이 존재하지 않으며 레인보우 테이블을 이용해도 비밀키를 얻을 수 없다.

외국의 경우 비밀번호+SSL을 쓰기 때문에 우리나라보다 사고가 적다고 주장하는 사람들이 있는데, 이는 사실과 다르다. 이미 제우스 등 악성코드에 의해 이미 엄청난 해킹 사건들이 발생했으며, 현재까지 훔쳐간 돈만 하더라도 7,000만 달러에 이른다.

- 공인인증서 vs. 비밀키를 사용한 인증
또한 사람들은 우리나라의 교통카드같이 스마트카드에 비밀키를 저장하는 방식을 제안하기도 한다. 사실 아직까지 비밀키를 사용하는 교통카드는 큰 문제없이 잘 사용되어 왔다(물론 작은 사고들은 보고된 적이 있긴 하다).

그러나 이에 대해 좀더 자세히 살펴보면 큰 문제를 발견할 수 있다. 비밀키를 인증에 사용하기 위해서는 사용자가 인증해야 할 시스템이 사용자의 비밀키를 또한 알아야 한다.

예를 들어, 우리나라 마을버스에서는 교통카드를 사용할 수 있다. 일반적으로 마을 버스의 교통카드 시스템이 서버와 온라인 통신을 한다고 생각하는가?

아마 불가능할 것이며 그렇다고 하더라도 이는 통신의 낭비다. 그럼 이런 경우 어떻게 인증이 가능할까?

우리나라의 교통카드 시스템을 자세히 들여다 볼 수는 없지만 쉽게 시스템을 유추를 할 수 있다. 사용자의 개인키는 Ku = HMAC(MK, U), 즉, 사용자의 ID U를 마스터 키(Master key) MK를 키로 사용해 HMAC 혹은 암호화한 결과로 계산하고 사용자 교통카드에 저장된다.

이 경우, 어떻게 통신이 불가능한 마을 버스 카드리더가 사용자의 U의 개인키를 유추할 수 있을까? 모든 사용자의 비밀키를 카드리더에 저장하는 것은 매우 비효율적임을 쉽게 알 수 있다.

이를 효율적으로 구현하기 위해서는 마스터 키 MK가 마을버스의 카드리더에 저장돼야 한다. 즉, 폐차된 마을버스의 카드리더기를 분석할 경우 MK를 구할 수 있고 MK가 노출되는 순간 우리나라 전체 교통카드 시스템은 마비되는 결과를 가지고 온다.

이와 달리 공개키 시스템에서는 마을버스의 비밀키는 따로 저장이 되며 이 비밀키가 노출이 되더라도 마을버스 한 대의 비밀키만 노출될 뿐이다. 그리고 마을버스의 공개키는 인증서를 이용하여 보호할 수 있으며 개인의 비밀키는 스마트 카드에 저장되고 인증서는 기존의 PKI와 같이 처리할 수 있다.

이 경우, 어떤 실체(entity)가 해킹이 되더라도 비밀키의 노출은 그 실체에 한정된다. 따라서 해킹이 성공하더라도 그 영향은 매우 적다. 이런 구현은 또한 공격자에게 싱글 포인트(single-point-of-attack)를 제공하지 않고 따라서 해킹의 효과를 최소화할 수 있다. 가장 유명한 OTP(One Time Password)로 알려진 RSA의 시큐어ID 또한 중국의 해킹 공격으로 마스터 키가 노출되어 매우 곤란한 점을 겪었다는 점 또한 주목할 만하다.

지금까지 설명한 것을 요약해보면, 제대로 구현이 될 경우 공인인증서(개인용 인증서)는 경쟁 솔루션에 비해 훨씬 더 안전하고 편리한 AAA(Authentication, Authorization, Accounting) 방식이다.


안전하고 편리한 공인인증서의 구현
현재까지 국내 공인인증서 구현은 안전하지 않으나 제대로 구현될 공인인증서(개인용 인증서)는 매우 편리하고 보안성이 높아야 한다는 점에 대해 논의했다.

그렇다면 과연 안전하고 편리한 공인인증서를 구현할 수 있을까?

예를 들어, 에스토니아의 경우 국가용 공인인증서를 USIM(Universal Subscriber Identity Module)에 구현해 안전하게 사용하고 있다. 모든 인증은 USIM에서 이뤄지기 때문에 USIM 자체만 안전하게 구현하고 여러 앱들을 USIM의 표준 API를 사용할 경우 안전한 구현을 할 수 있다. 이와 비슷한 방법을 우리나라에서도 구현할 수 있다고 생각한다.

안전한 공인인증서는 최소한 USIM과 같은 시큐어 하드웨어 스토리지(Secure Hardware Storage)와 트러스트존(Trustzone) 등을 사용할 경우 구현이 가능할 것이다.

이 경우 전화기의 운영체제가 루팅이 되더라도, 혹은 윈도우 운영체제가 루팅이 되더라도 안전성은 보장할 수 있을 것이다.

트러스트존은 사용자의 I/O 통로(Path), 즉, 디스플레이(display)와 키보드 입력을 안전하게 하고 공인인증 앱의 완전성(integrity)과 시큐어 소프트웨어(Secure software) 패치를 지원하도록 이용할 수 있다. 또한 USIM은 비밀키를 안전하게 보관하고 전자 서명 및 복호화를 수행하는데 사용한다.

몇 가지 단계로 나눠 생각해 보자. 먼저 공인인증서의 발급이 안전하게 이뤄져야 한다.

현재까지 발급된 전체 공인인증서의 비밀키는 이미 노출된 것으로 생각하고 공인인증기관과 USIM 사이에 직접 SSL을 사용해 인증서 발급이 이뤄져야 한다. 이렇게 발급된 인증서의 비밀키 부분은 USIM 안에 안전하게 보관하며 모든 전자 서명과 복호화는 USIM 내에서 이뤄져야 한다.

서명 단계에서 필요한 사용자 입력은 트러스트존과 USIM 툴킷을 사용해 하드웨어적으로 보호한다. 이렇게 함으로써 루팅이 되더라도 비밀키의 안전성을 보장할 수 있으며 서명 본문의 완전성을 보장할 수 있다.

또한, USIM 툴킷을 사용해 개발된 USIM 앱은 사용자가 서명 내용에 대해 확인할 수 있는 기능을 반드시 제공해야 한다. 디스플레이 또한 USIM 및 필요한 경우 트러스트존을 사용해 안전하게 구현할 필요가 있다.

이렇게 구축하고 간단한 기본 API를 구현할 경우, 사용자는 항상 같은 UI를 가지고 항상 동일한 행동을 함으로써 UX 측면에서 익숙하게 되고 안전성 측면에서는 하드웨어를 이용한 안전성을 보장할 수 있다.

안전하고 편리한 공인인증서가 필요하다
지난 15년간 우리나라는 공인인증서를 안전하지 않고 불편하게 사용해 왔다. 그리고 이제 공인인증서는 사라질 위기에 처해 있다.

UI의 문제점, 그리고 액티브X의 문제점 때문에 공인인증서를 없애는 것은 말이 되지 않는다고 생각한다.

공인인증서는 최근 널리 사용되고 있는 하드웨어 기반의 보안 기술들을 사용할 경우 안전하고 편리한 개인인증 수단으로 사용될 수 있다.

익명 인증서(Anonymous Credential)를 사용해 개인의 사생활 보호 또한 가능할 것이다. 따라서 다른 대체 수단들과 더불어 안전하고 편리한 공인인증서의 구현 또한 고려돼야 한다고 생각한다. editor@itworld.co.kr