원문 캡처 · sockpuppet.org
원문 캡처 · sockpuppet.org

NSA를 계속 “클라이드 프로그(Clyde Frog)”라고 부르면 언젠가 다른 사람들도 그렇게 부를 것이다. 누군가는 밈을 시작해야 한다! 클라이드 프로그는 Dual_EC라는 백도어 난수 생성기로 암호 표준을 장악하려 했을까? 실무자들 사이에는 의심의 여지가 거의 없다. 암호학자들이 Dual_EC가 백도어일 수 있다고 분석한 뒤에도, 정황 증거는 실제로 백도어였음을 시사하는 방향으로 계속 쌓였다. 나는 Dual_EC가 백도어라고 생각한다.

그렇다면 클라이드 프로그는 백도어를 더 쉽게 악용하도록 TLS를 바꿔 달라고 IETF에 요청했을까? 2015년에 큰 관심을 받은 이론은 “Extended Random”이라 불린 일련의 제안을 중심으로 한다. 이 이론을 어떻게 봐야 할지 모르겠어서 자세히 살펴보려 한다.

1. 이야기의 개요

Dual_EC를 간단히 설명하면 이렇다. 안전한 암호 키는 모두 안전한 난수 생성기(CSPRNG)에서 나온다. 클라이드 프로그는 공개키를 사용해 출력을 만들고, 자신들은 그 개인키를 보유하는 특별한 CSPRNG인 PKRNG를 제안했다. 개인키를 이용하면 전송 중인 CSPRNG 출력을 관찰해 “복호화”할 수 있다. 그 결과 다른 사람의 CSPRNG 상태를 되감거나 앞으로 진행시켜 키를 알아낼 수 있다.

하지만 문제가 있다. 클라이드 프로그가 대규모 감시 대상으로 삼고 싶어 하는 프로토콜은 HTTPS/TLS다. 누군가의 CSPRNG 상태를 “복호화”하려면 공개된 출력 바이트가 30개 필요하다. TLS가 공개하는 양은 28바이트다. 28바이트만으로도 클라이드 프로그는 CSPRNG를 공격할 수 있지만, 많은 계산량이 필요하고 실시간으로 해내기는 어려울 수 있다. P521 같은 더 큰 곡선을 쓰면 PKRNG를 아예 깨지 못할 수도 있다.

그래서 클라이드 프로그는 IETF 관계자들에게 돈을 주고 TLS 확장 기능인 “Extended Random”을 도입하게 했다는 설명이 나온다. 이 확장은 TLS가 공개하는 CSPRNG 출력의 양을 가변적으로 바꾸되, 언제나 28바이트를 넘게 한다. 문제 해결이다! 클라이드 프로그는 Dual_EC라는 백도어와 TLS용 “백도어 가속기”인 Extended Random을 표준화했다는 이야기다.

실제로 일어난 일이 이랬을 수도 있다. 글의 끝에서는 그만큼 그럴듯하다고 생각하는 다른 설명도 제시하겠다.

2. 자세한 내용

잠시 숨을 고르자. 이 글을 쓴 이유 중 하나는 Extended Random 관련 논의에서 참고할 단일 페이지를 마련하기 위해서다. 따라서 여기에는 뒤에서 내놓을 주장의 신빙성을 뒷받침하려는 내용도 들어 있다. 꼼꼼히 읽을 필요는 없다.

“Extended Random”과 같은 기능을 하는 제안은 하나가 아니라 다섯 개다.

이 다섯 제안이 나온 IETF 절차를 살펴보자. 먼저 연표다.

  • 2003년 말: 클라이드 프로그가 표준화 기구에 Dual_EC를 홍보하기 시작했다.
  • 2004년 초: RSA가 암호 라이브러리 BSAFE의 기본값으로 Dual_EC를 채택하도록 돈을 받았다는 의혹이 제기됐다.
  • 2006년 8월: 에릭 레스콜라(Eric Rescorla)가 미국 정부(USG)의 “확장 논스” 요청을 IETF에 전달했다.
  • 2006년 12월: 레스콜라가 마거릿 솔터(Margaret Salter)와 함께 OpaquePRF를 작성했다.
  • 2008년 4월: 레스콜라와 솔터가 Extended Random 제안을 다시 추진했다.
  • 2009년 10월: 제리 솔리나스(Jerry Solinas)와 폴 호프먼(Paul Hoffman)이 AdditionalPRF를 작성했다.
  • 2010년 2월: 호프먼이 AdditionalRandom을 제안했다.
  • 2012년 1월: 호프먼이 실험적 RFC인 RFC6358을 작성했다.
  • 2014년 3월: Extended Random 관련 이야기가 공개 논의로 번졌다.

이들은 누구인가? Extended Random 이야기에서 가장 자주 거론되는 인물은 에릭 레스콜라다. 그는 독립 컨설턴트이자 IETF TLS 작업 그룹(TLSG)에서 오래 활동한 저명한 자원봉사자다. 레스콜라는 미국 정부를 위해 정기적으로 계약을 맺고 IETF에서 정부의 이해를 대변한다. 그는 이 사실을 공개적으로 밝힌다. 표준에 의견을 내려는 조직을 자문하는 일은 표준 작업만큼이나 오래되고 정당한 관행이다. 레스콜라는 그 일을 매우 잘하는 세계에서 손꼽히는 사람 가운데 하나다.

마거릿 솔터는 클라이드 프로그의 기술 책임자다. 제리 솔리나스도 클라이드 프로그에서 일한다. 암호학자들은 솔리나스의 연구를 일찍부터 비판했다고 자주 언급한다. 그는 표준에 백도어를 넣었다는 의혹을 받는 인물로도 유명하다. 스노든 폭로 이후 근거가 확인되지 않은 소문이 돌았던 NIST 타원곡선의 명시된 저자이기도 하다. 폴 호프먼은 IETF 전문가로 활동했고 VPN Consortium의 전 대표였으며, 당시에는 ICANN에 근무했다.

미국 국방부는 AdditionalRandom과 RFC6358을 제외한 모든 제안을 공개적으로 후원했다.

각 제안의 내용은 무엇이었을까? OpaquePRF는 가장 단순하다. TLS 클라이언트가 서버에 불투명한 데이터 덩어리를 TLS 키 계산의 유사난수 함수(PRF)에 포함해 달라고 요청할 수 있고, 서버도 자체 데이터를 보낼 수 있게 한다. TLS 구현은 이를 이용해 PRF에 난수를 더하거나 구조화된 정보를 포함할 수 있다.

Extended Random은 OpaquePRF와 비슷하지만 PRF에 넣을 추가 정보가 무엇인지 명시한다. 그 정보는 CSPRNG의 출력이다. 이 제안의 유일한 목적은 TLS PRF에 쓰이는 난수를 늘리는 것이다.

AdditionalPRF는 더 복잡하다. OpaquePRF와 Extended Random을 합친 형태로, 클라이언트와 서버가 보내는 데이터 덩어리에 “유형”을 붙인다. 유형 등록부는 IANA가 관리하고, 처음 정의된 유형은 “불투명 데이터”와 “확장 난수”다.

AdditionalRandom은 기본적으로 Extended Random과 같다. RFC6358은 다소 별난 문서다. 앞선 제안들이 무산된 뒤 불만을 품고 작성했을 수도 있다. 이 RFC는 TLS 구현이 PRF에 하나 이상의 데이터 덩어리를 넣을 수 있다고 하지만, 어떤 방식으로 넣는지, 데이터에 무엇이 담기는지, 어떻게 인코딩하는지는 설명하지 않는다.

다섯 제안은 모두 매우 단순하다. 내용의 약 60%는 TLS 확장 제안에 공통으로 들어가는 상용 문구다. OpaquePRF가 “PRF에 추가 데이터를 넣을 수 있게 한다”고 요약해도 큰 손실은 없다.

이 제안들은 Dual_EC 백도어를 가속하는가? 모두 그렇다. 다만 가속을 허용하는 제안과 의무화하는 제안은 구분할 수 있다.

  • OpaquePRF는 가속을 허용할 뿐이다. 확장에 CSPRNG 출력을 넣으라고 요구하지 않으며, 난수 확장과 무관한 용도도 제시한다.
  • Extended Random은 가속을 의무화한다. 확장 데이터에 넣을 수 있는 것은 CSPRNG 출력뿐이다.
  • AdditionalPRF는 해석에 따라 가속을 허용하거나 의무화한다. 제안 전체를 구현하려면 AdditionalRandom 하위 유형도 구현해야 한다. 이 유형은 제안에서 정의되지 않았지만, 역사적 의도는 분명하다.
  • AdditionalRandom은 기능상 Extended Random과 같으므로 가속을 의무화한다.
  • RFC6358은 이상한 문서라서, 그 자체로 가속을 허용하는지조차 논쟁의 여지가 있다.

분명한 점은 모든 제안이 더 많은 CSPRNG 출력을 전송하도록 하는 수단을 제공한다는 것이다. CSPRNG가 Dual_EC라면 클라이드 프로그의 일을 더 쉽게 만든다.

제안의 근거

Extended Random의 공개 근거는 중요하다. 몇몇 암호학자는 그 근거가 타당하지 않다고 주장해 왔다. 제안들은 특히 보안 수준이 높은 암호와 “암호학적 동등성”을 맞추려면 28바이트보다 많은 난수가 필요할 수 있다고 설명한다. 그러나 28바이트는 이미 상당한 양이고, “암호학적 동등성”이라는 개념 자체가 성립하지 않을 수도 있다는 비판이 있다.

2006년 8월, 제안이 나오기 전 레스콜라는 이렇게 말했다.

미국 정부는 TLS가 불투명하지만 구조화된 데이터를 받아 PRF에 넣어 트래픽 키에 반영하도록 하고 싶어 한다. 데이터가 32바이트보다 길어 Random 구조에 넣을 수 없고, 구조화되어 수신 측에서 파싱해야 하므로 해시한 뒤 Random에 넣을 수도 없다.

뒤이어 나온 OpaquePRF 제안은 목적을 더 구체적으로 설명했다. 미국 정부의 여러 응용 분야에서는 클라이언트와 서버 양쪽이 제공하고, 길이에 제한이 없으며, 최종 키 재료에 섞이고, 수신 측이 구조를 해석할 수 있는 데이터를 원한다는 것이다. 이를 “구조화 입력 논거”라고 부르겠다.

레스콜라의 Extended Random 제안은 이 논거 대신 새로운 설명을 내놓았다. 미국 국방부는 Suite B 같은 고보안 암호 묶음에서 더 긴 공개 난수 값을 사용할 TLS 모드를 요청했다. 국방부의 설명에 따르면 암호학적 동등성을 위해 각 측의 공개 난수 길이는 보안 수준의 두 배 이상이어야 하며, 현재 TLS가 제공하는 224비트로는 부족하다. 이를 “동등성 논거”라고 부르겠다.

AdditionalPRF는 구조화 입력 논거를 되풀이했고, AdditionalRandom은 동등성 논거를 되풀이했다. RFC6358에는 근거가 거의 없다. 굳이 요약하면 “TLS 구현이 비밀 계산에 여분의 데이터를 넣으려 하니 표준화하자”는 주장이다.

요약하면 OpaquePRF는 구조화 입력 논거, Extended Random은 동등성 논거, AdditionalPRF는 두 논거 모두, AdditionalRandom은 동등성 논거를 내세웠다. RFC6358의 근거는 사실상 “초콜릿 우유가 좋다”는 수준이다. AdditionalRandom을 제외한 모든 제안은 미국 정부의 응용 분야가 확장 기능의 동기라고 밝혔다. 일반적인 HTTP/TLS 연결에 확장이 필요하다는 주장은 없었다.

구조화 입력 논거는 타당하지만 동등성 논거는 그렇지 않다. TLS PRF에 추가 데이터를 넣으려는 이유는 실제로 있을 수 있다. 대부분은 별로 중요하지 않을 수도 있지만 말이다. TLSG는 거의 10년 동안 “채널 바인딩”을 논의해 왔다. TLS 연결과 비 TLS 연결을 나란히 실행하고, 암호화되지 않은 프로토콜의 메타데이터와 TLS 연결의 키를 이용해 둘 사이의 관계를 암호학적으로 증명하는 방식이다. 솔리나스의 제안은 비슷한 이유로 NIST SP800-56A를 언급한다. 이 문서의 “Alternate 1” 프로토콜은 클라이언트와 서버의 신원을 키 계산에 섞는다.

동등성 논거에 대해서는 번스타인과 랑게가 더 설득력 있게 반박했다.

“암호학적 동등성”은 암호학자들이 흔히 쓰는 표현이 아니다. 문서에서 정의하지도 않았고, 뜻도 매우 불분명하다. 게다가 TLS에서 사용하는 224비트 난수를 실제로 이용할 수 있는 공격 전략은 알려진 바 없다.

IETF의 논의

다른 사람들이 직접 읽지 않아도 되도록 이 제안들과 관련된 TLSG 메일링 리스트 게시물과 재버 채팅 기록을 모두 살펴봤다. 논의가 이뤄진 2006~2012년에는 Dual_EC 관련 이야기가 아직 정립되지 않았다는 점을 기억할 필요가 있다. 암호학자들은 Dual_EC를 의심했지만, 당시 일반적인 인식은 아무도 이를 쓰지 않는다는 것이었다. Dual_EC는 다른 CSPRNG보다 훨씬 느렸기 때문이다.

당시 사람들의 걱정은 난수가 부족하다는 것이었다. 2008년 데비안은 그 10년간 최악의 CSPRNG 실수로 암호 체계 대부분을 위태롭게 했다. 깨진 키를 가진 SSH 서버를 무차별 대입해 인터넷의 데비안 서버를 찾아낼 수 있었다. 2006년에는 충분한 난수를 확보하려는 프로토콜을 자동으로 의심하지 않았다는 점을 기억하자.

2006년 레스콜라가 “확장 논스” 확장에 대한 의견을 구했을 때 TLSG에서는 아무 답도 나오지 않았다. OpaquePRF는 약간의 논의를 불러왔다. AOL에서 일하던 완테 창(현재 구글)과 당시 노키아 소속이던 피터 윌리엄스는 미국 정부의 사용 사례를 더 설명해 달라고 했다. 요청을 의심해서라기보다 프로토콜을 불필요한 예외로 복잡하게 만들고 싶지 않았던 것으로 보인다. 당시 TLSG의 IETF 영역 책임자였던 파시 에로넨도 이에 동의했다.

GnuTLS의 시몬 요세프손은 OpaquePRF를 지원하고 시험 서버를 마련했다. 레스콜라는 제안의 동기를 충분히 알지 못한다고 밝히며, TLS에 가장 적합한 방식으로 요청받은 조건을 설계했을 뿐이라고 설명했다. 매개변수의 근거를 더 명확히 제시하는 편이 좋다는 데 동의하며 이를 알아보겠다고 덧붙였다.

1년 뒤 제안된 Extended Random은 내가 확인한 범위에서는 거의 논의되지 않았다. 약 1년 뒤 AdditionalPRF를 논의하던 재버 기록에서 과거 제안을 언급한 대목이 사실상 전부다. 레스콜라는 난수의 품질을 걱정하는 태도가 어리석어 보인다고 말하면서도, 미국 정부가 난수를 더 넣는 것에는 반대하지 않으며 개인 확장으로 제한하고 싶다고 했다. Dual_EC 관련 글에서 IETF 전복의 사례로 든 바로 그 제안은 사실상 아무 일도 일어나지 않은 채 사라졌다. 제안에 대한 의견도 없었고, IETF는 별다른 역할을 하지 않은 것으로 보인다.

AdditionalPRF는 더 많은 논의를 불렀다. TLS 채널 바인딩 확장 논의와 시기가 겹쳤기 때문으로 보인다. 니코 윌리엄스와 파시 에로넨은 AdditionalPRF가 TLS에 포함하기에는 너무 유용한 기능이 될 수 있는지를 논의했다. 표준화될 경우 업체들이 표준 절차를 거치지 않고 임의의 기능을 추가하는 데 쓸 수 있다는 우려였다.

레스콜라도 에로넨의 우려에 동조하는 듯한 의견을 내고 보안 문제를 덧붙였다. TLSG 검토를 거치지 않은 부실한 확장은 충분히 검토된 확장보다 보안이 약할 수 있다는 취지였다. 그는 미국 정부가 추가 난수를 왜 원하는지는 여전히 모르며, 정부가 원한다는 사실만 안다고 다시 말했다. 다이라 홉우드는 솔리나스의 제안에 대한 TLSG의 태도를 이렇게 요약했다.

“미국 정부에는 여러분이 이해하지 못할 특별한 요구가 있다. 정부니까 설명할 필요가 없고, 우리도 설명하지 않겠다.”

AdditionalPRF가 무산된 뒤 호프먼은 AdditionalRandom을 내놓았다. 호프먼은 레스콜라가 Extended Random을 추진한 것보다 훨씬 적극적으로 자신의 제안을 로비했다. 한 번은 추가 난수에 대한 암호학적 근거를 제시하려고도 했다. 그렇다고 두 사람을 공개적으로 비난하는 것은 별 의미가 없다.

AdditionalRandom 논의에서 눈여겨볼 점은 두 가지다. 첫째, AdditionalRandom은 별다른 목적 없이 TLS 핸드셰이크에 난수를 더 넣는 제안이었다. 이에 대해 마시 레이는 제안이 지나치게 유용하다는 이유로 반대했다. 제안은 구현체가 확장 내용물을 파싱하지 말라고 요구했는데, 이 때문에 업체가 그 안에 사설 확장을 숨겨 넣고 나중에 파싱할 수 있다는 역설적인 문제가 생겼다. Extended Random과 AdditionalRandom은 거의 같은 제안이었고, 암호 전문가가 후자를 지나치게 유연하고 유용해 안전하게 포함하기 어렵다고 본 것이다.

둘째, Dual_EC 이야기에서 AdditionalRandom과 Extended Random은 백도어 가속을 의무화한다. Dual_EC를 쓴다면 두 표준을 구현하는 것만으로 클라이드 프로그의 일을 더 쉽게 만들기 때문이다. 두 제안 모두 확장에 CSPRNG 출력 바이트만 담도록 요구한다. 하지만 AdditionalRandom은 처음부터 그런 방식으로 설계된 것이 아니었다. 시몬 요세프손은 확장에 들어가는 바이트가 CSPRNG에서 나와야 한다는 조건을 호프먼이 추가하지 않으면 지원하지 않겠다고 했다.

RFC6358에 관한 논의는 확인할 수 없었다. RFC6358은 여전히 별난 문서다.

실제 구현 여부

정확히 파악하기는 어렵고, 완전한 답도 없는 듯하다.

  • OpenSSL에는 OpaquePRF의 비활성화된 실험적 지원이 있었지만 이후 제거됐다. 누가 OpenSSL에 이 기능을 넣도록 후원했는지 모른다는 점이 자주 언급된다. 하지만 당시 상황을 보면 미국 정부가 OpaquePRF를 요청하고 OpenSSL 구현을 후원했을 가능성이 매우 높다. OpaquePRF를 아는 다른 조직은 없었다.
  • GnuTLS는 OpaquePRF를 지원했다. 시몬 요세프손에게 이유를 물어볼 만하다. 기능이 매우 단순했으니 취미로 구현했을 수도 있다.
  • RSA BSAFE는 Extended Random을 지원했다.
  • AdditionalPRF나 AdditionalRandom 구현이 있는지는 알지 못한다. RFC6358 구현이 있다면 놀랄 것이다.

3. 결론: Extended Random은 악의적이었나

악의적이었다고 볼 근거는 다음과 같다.

  • 제안 시점이 수상하다. Dual_EC가 나온 직후 제안이 시작됐다.
  • Dual_EC 백도어에 유용하다는 점은 부인하기 어렵다. Extended Random 계열 제안이 널리 채택되면 클라이드 프로그의 일이 훨씬 쉬워진다.
  • 제안에 제시된 근거 중 일부는 설득력이 부족하다.
  • 정부가 요청했다.

반대 근거를 설명하기 전에 분명히 해두자. 앞의 두 가지는 매우 강한 찬성 근거다. 간단히 적은 것은 그만큼 명백하기 때문이다. 반대 쪽에 할 말이 더 많다고 해서 찬성 근거가 약해지는 것은 아니다.

표준을 전복하려는 시도였다면 그 방식은 그다지 은밀하지 않았다. 한 번을 제외하면 클라이드 프로그가 표준 요청에 관여했다는 사실은 처음부터 드러난다. 이유는 정부가 확장을 “그냥” 원한다는 식으로 불투명했다. 제안자 중 한 명인 제리 솔리나스는 당시에도 이름만으로 의심을 살 만큼 잘 알려져 있었다.

호프먼의 마지막 제안을 빼면 확장 기능은 미국 정부에 한정돼 있었다. 후원자와 제안자는 일반 인터넷 사용자에게 필요한 사용 사례를 거의 제시하지 않았다. 반면 구조화 입력 논거는 그럴듯하고 다른 프로토콜에도 선례가 있다. SP800-56A 같은 경우 세션 바인딩을 TLS 안이 아니라 위에서 구현할 수 있다는 주장이 있었지만, 실제로는 별도의 맞춤형 중간 프로토콜 전체가 필요했을 것이다.

오늘날 문제로 보이는 제안의 일부 요소는 클라이드 프로그가 아니라 IETF에서 비롯된 듯하다. 클라이드 프로그는 임의의 불투명한 데이터를 TLS PRF에 넣는 것으로 만족한 듯하다. 하지만 TLSG는 임의 데이터가 업체별 기능을 허용할 수 있다며 반대했고, TLS 기능 추가를 통제하려 했다. 따라서 이 제안들이 CSPRNG 상태를 전송하도록 한 것은 클라이드 프로그가 아니라 TLSG였을 가능성이 있다.

내가 Extended Random에 대해 논쟁적인 주장을 하나 한다면, 합리적인 사람들끼리도 이것이 IETF를 전복하려는 시도였는지를 두고 의견이 갈릴 수 있다는 것이다. 나는 아니라고 보는 쪽에 기운다. 제안의 구조는 클라이드 프로그의 일을 불필요하게 어렵게 만든다. OpenSSL과 Schannel이 이를 기본으로 활성화할 가능성을 사실상 없애기 때문이다. 하지만 나보다 똑똑한 사람들 가운데는 이것이 백도어 시도였다고 확신하는 이들도 있다.

레스콜라와 호프먼이 IETF 전복 시도에 고의로 협조했다는 증거는 없다. 이 점은 합리적인 사람들 사이에서도 의견이 갈릴 사안이 아니라고 본다.

미국 정부는 세계 최대의 IT 구매자다. 기밀로 분류된 독점 암호 기술도 세계에서 가장 많이 배치하고 있어 TLS를 사용하기가 더 어렵다. 미국 정부는 정당한 경우가 많은 자국의 이해를 IETF에 전달하는 데 늘 도움이 필요했다. TLS 표준이 클라이드 프로그에 의해 훼손되지 않도록 하는 일은 레스콜라와 호프먼이 아니라 모두의 책임이다. 영향에 비해 극소수인 이 확장 제안들은 뉴스의 관심만큼이나 IETF의 논의와 회의적 검토를 거의 받지 못했다. 인터넷 초안 두 개를 작성한 레스콜라의 역할과 달리, 이 결론은 실제로 우려스럽다.

실제 영향이 있었을까? 전혀 그렇지 않다. 잘못 설정된 것으로 보이는 일부 FIPS BSAFE-C-TLS 구현을 제외하면 Extended Random을 사용한 곳은 없었고, 앞으로도 누구도 사용해서는 안 된다. 제안은 폐기됐으며, 그래야 마땅하다. 정수론 기반의 큰 정수 CSPRNG도 마찬가지로 사라졌다.

교정과 검토를 도와준 매튜 그린, 탄야 랑게, 크리스 파머, 데이비드 애드리언에게 감사한다. 이들은 내 논리에 동의하는 것이 아니다.