Search

'DigiNotar'에 해당되는 글 2건

  1. 2011.10.14 DigiNotar의 구라 인증서에 대한 대처
  2. 2011.10.13 가짜 구글 인증서

DigiNotar의 구라 인증서에 대한 대처

Security 2011. 10. 14. 10:56 Posted by 알 수 없는 사용자
앞서 작성한 DigiNotar의 가짜 구글 인증서에 이어서 쓰는 글입니다.

IE의 경우 MS에서 windows update를 통해 처리한 것으로 들었습니다. 여기서 처리했다 함은 웹브라우저가 DigiNotar를 Root CA로 인정하지 않도록 하는 것을 말합니다. 심플한 대처지요.

파이어폭스의 경우에도 업데이트를 통해 동일한 처리를 했고, 업데이트가 싫으신 분은 설정에 인증서 관리에 가셔서 직접 제거하셔도 된다고 합니다.

크롬도 마찬가지로 제외시켰다고 했는데, 크롬을 사용하고 있었다면 '혹시 내가 당하지 않았나?'하는 생각을 하지 않아도 됩니다. 왜냐하면 이 사건이 알려진 것이 크롬의 역할이 컸으니까요.

구글의 지메일 포럼에다가 누가 이런 글을 올렸는데, 크롬이 인증서가 이상하다며 경고 메시지를 보내줬다는 것이죠. 그래서 이게 man-in-the-middle attack이 아닌가하고 질문을 했고, 세상에 알려지게 되었습니다.

크롬 입장에서는 은근 자랑할만한 사건이 생긴 것이 되겠네요.

크롬이 경고를 날릴 수 있었던 것은 certificate pinning이라는 개념을 크롬이 도입하고 있어서인데, 개념이라고 하니 무척 고급 기술이 들어간 것 같지만, 별거 아니고, 특정 사이트의 인증서에 대한 root CA 리스트를 강제해두는 것입니다. 좀 더 쉽게 말하면 구글의 인증서를 인증해줄 수 있는 기관은 여기 여기뿐이다라고 정해두는 것이죠. 즉, 사이트별로 root CA whitelist를 가지는 것입니다.

구글은 (2011년 5월 4일 시간 기준으로) 구글 사이트들에 대한 인증을 해줄 수 있는 기관을 Verisign, Google Internet Authority, Equifax, GeoTrust 이렇게 4개의 인증기관으로 한정지어 두고 있습니다. 그러니 DigiNotar가 비록 root CA로써 활동하고 있는 인증 기관임에도 여기서 발행된 *.google.com에 대한 인증서는 크롬 입장에서는 '이상한데?' 하고 의심할 수 있게 되는 것이죠.

'Security' 카테고리의 다른 글

물건 분실을 파악하는 좋은 방법?  (0) 2011.10.14
RFID Tag Coupling  (0) 2011.10.14
가장 비싼 1바이트의 실수  (0) 2011.10.14
HSTS: HTTP Strict Transport Security  (0) 2011.10.14
가짜 구글 인증서  (0) 2011.10.13

가짜 구글 인증서

Security 2011. 10. 13. 14:23 Posted by 알 수 없는 사용자
친구(@skyisle)의 페이스북 글에서 가짜 구글 인증서 사건이 있었다는 것을 알게 되었다. DigiNotar라는 곳에서 구글(정확히 말하면 *.google.com)에 대한 인증서를 발행했다는 것이다. DigiNotar는 네덜란드의 인증 기관(certificate authority, CA)이다.

문제는 DigiNotar가 Root CA 중에 하나라는 것인데, 이것이 왜 문제인지 내가 아는데까지 간단히 설명을 해보면,

우선 공개키 방식에 대해서 이해할 필요가 있다. 공개키 방식은 1977년인가에 Diffie와 Hellman이라는 두 사람이 공식적으로 제안한 것으로 유명하다. 그 이전까지는 하나의 키를 두 사람이 남들 모르게 공유하고 이것을 가지고 암호화 및 복호화를 하는 방식에만 모두가 집중하고 있었다. 그래서 키를 어떻게 몰래 나눠가질 것인가가 주요 이슈였다.

서로 뭔가 비밀 정보를 알고 있다면 그것을 이용해서 암호화해서 키를 보내주면 되는데, 뭔가 비밀 정보를 이미 공유하고 있다면 이미 그 자체가 키가 아닌가! 그래서 예전에는 키를 보낼 때 등기 우편으로 보내거나 사람을 사서 안전하게 전달한다는 내용이 논문이 당연하다는 듯이 기술되어 있다. 하지만 이건 사람이 개입되는 것이니 비용이 높고 속도가 느리다. 네트워크를 통해서 쉽게 할 수는 없을까? 하고 당연한 의문이 생겼을 터.

공개키 방식은 말 그대로 키를 공개할 수 있다는 것인데, 그렇게만 된다면 키를 누가 보게 되더라도(즉, 도청을 당할 위협을 고려하지 않고) 필요한 녀석들에게 던져줄 수가 있다. 하지만 공개된 로또 번호가 의미가 없듯, 남들 다 아는 주식 정보가 의미가 없듯, 키가 공개되는 건 이미 그 자체로 의미가 없다.

그럼에도 불구하고 이런 개념이 나올 수 있었던 것은 키가 하나가 아니라 두개이기 때문이다. Key pair를 만들어서 하나는 비밀로 숨기고 하나를 공개한다. 내부적으로 많은 알고리즘이 있을 수 있지만 다음 규칙을 따르면 공개키 방식에 사용될 수 있다.

(1) 공개키로 암호화한 것은 비밀키로 복호화할 수 있다. 반대로,
(2) 비밀키로 암호화한 것은 공개키로 복호화할 수 있다.

첫 번째 방식을 이용해서 안전하게 데이터를 전달하거나 혹은 비밀키를 전달한다.
두 번째 방식을 이용해서 전자서명을 한다.

이것이 디피와 헬만이 제안한 내용이다. 획기적이고 멋진 아이디어지만 여기서 문제가 하나 있다. 공개키가 말 그대로 공개되기 때문에 다른 녀석이 나를 사칭하여 자신의 공개키를 내 것이라고 다른 사람들에게 거짓말을 할 수 있기 때문이다.

즉, A가 B에게 어떤 비밀 메시지를 보내려고 B의 공개키로 암호화를 한다. 그럼 B는 자신만의 비밀키로 풀어서 그 내용을 볼 수가 있다. B의 공개키는 공개되어 있지만 누구도 비밀키는 모르므로 비밀 메시지를 볼 수가 없다.

이 때, E가 B인척 A를 쉽게 속일 수 있다. A가 B의 공개키가 뭔지 알아볼 때 E가 끼어들어 자신의 공개키를 A에게 알려주면서 "이거 B꺼야." 한다. A는 E의 공개키로 암호화 한다. E는 자신의 비밀키로 풀어서 메시지를 쉽게 읽을 수 있다.

이것 때문에 나온 것이 certificate이다. (인증서 개념은 역시 70년대 말에 MIT의 어떤 학부 학생의 졸업 논문에서 제안되었다고 하는데, 학부생이라니! MIT는 MIT다.) 인증 기관이 있어서 이 공개키는 B의 것이 맞소, 하고 인증해주는거다. E가 이것이 B의 인증서이다하면서 자기 인증서를 A에게 들이 밀어도 A가 인증기관에 알아보면 쉽게 이것이 뻥이라는 것을 알 수 있게 된다.

현재 인증서는 누구든 발행할 수 있고 대신에 chain을 형성하면 된다. Chain을 형성해야 한다는 것 자체가 아무나 발생할 수 없다는 소리가 되긴 하지만... 여튼 누군가가 "이 물건이 믿을만한 것이요."라고 말했을 때 못 믿겠다면 그 사람이 믿을만한 사람인지 또 누군가에게 물어봐야 한다. 이렇게 점점 연결 고리가 형성되는데 이 방식대로라면 최후에 절대 신뢰할 수 있는 누군가가 있어야 한다. 뭐, 정부의 인증! KS 마크! 이런 거라고 보면 될까? 비유가 안 좋았다. 하여튼 이걸 Root CA라고 한다.

이야기가 굽이굽이 많이도 돌았다. 결론적으로 하고 싶은 이야기는 DigiNotar는 root CA라서 여기서 발행된 인증서를 봤을 때 사용자는 믿을 수 있다고 생각한다.

이 인증서가 DigiNotar가 직접 발행한 건지 아니면 누군가가 DigiNotar를 해킹해서 한 건지는 내가 본 기사에서는 누구도 다루지 않았지만 여튼 이 인증서는 유효한 인증서였고 이란에 있는 많은 사용자들이 이 가짜 인증서를 사용했다. 아까 말했듯 인증서에는 공개키가 있고 사람들은 이 조작된 공개키를 암호화에 활용했을 것이다. 적발될 때까지 두 달 정도 사용되었다고 하니 꽤 많은 사람들의 지메일이나 구글독스가 털렸을 수도 있겠다.

여기 위키 페이지가 관련 링크로 넘어가기 좋다.

어떻게 적발되었고, 현재는 어떻게 대처하고 있는지는 다음 번으로 미룬다. 힘들다.

'Security' 카테고리의 다른 글

물건 분실을 파악하는 좋은 방법?  (0) 2011.10.14
RFID Tag Coupling  (0) 2011.10.14
가장 비싼 1바이트의 실수  (0) 2011.10.14
HSTS: HTTP Strict Transport Security  (0) 2011.10.14
DigiNotar의 구라 인증서에 대한 대처  (0) 2011.10.14