NSAKEY

_NSAKEY는 1999년 크립토님 코퍼레이션(Cryptonym Corporation)의 앤드루 D. 페르난데스가 윈도우 NT 4.0에서 발견한 변수 이름이다. 이 변수에는 1024비트 공개 키가 포함되어 있었다. 공개 키는 공개 키 암호 방식에서 암호화 및 디지털 서명 검증(복호화나 서명에는 사용되지 않음)을 위해 사용된다. 그러나 이름 때문에 미국 미국 국가안보국(NSA)이 모든 윈도우 사용자의 보안을 무력화할 수 있게 해주는 키가 아니냐는 추측이 제기되었다. 마이크로소프트는 이러한 추측을 부인하며, 해당 키의 이름은 NSA가 미국 암호 기술 수출 통제의 기술 검토 기관이었기 때문에 붙여진 것이라고 밝혔다.

개요

마이크로소프트는 마이크로소프트 암호화 API에서 사용하는 모든 암호화 서비스 공급자(CSP)가 RSA 디지털 서명을 갖출 것을 요구한다. 마이크로소프트가 승인한 공급자만 CryptoAPI와 함께 사용할 수 있기 때문에, 산업안보국(BIS)이 시행하는 수출 관리 규정(EAR)에 따라 이 운영 체제의 수출용 버전을 규제 준수 상태로 유지할 수 있다.

마이크로소프트가 주 키와 예비 키라는 두 개의 키를 사용하며, 둘 중 하나만으로도 유효한 서명을 생성할 수 있다는 사실은 이미 알려져 있었다. 윈도우 NT 4.0용 서비스 팩 5를 출시할 때, 마이크로소프트는 윈도우 레지스트리 및 보안과 같은 윈도우 기능을 노출하는 라이브러리인 ADVAPI32.DLL에서 디버깅 심볼을 제거하지 않는 실수를 저질렀다. 크립토님의 수석 과학자인 앤드루 페르난데스는 _KEY 변수에 저장된 주 키와 _NSAKEY라는 이름이 붙은 두 번째 키를 발견했다. 페르난데스는 자신의 발견을 공개했고, 이는 두 번째 키가 미국 미국 국가안보국(NSA)이 모든 윈도우 사용자의 보안을 무력화할 수 있게 한다는 가능성을 포함하여 수많은 추측과 음모론을 불러일으켰다.

컴퓨터, 자유 및 프라이버시 컨퍼런스(CFP2000) 2000년 회의 발표에서 전자 프라이버시 정보 센터(EPIC)의 선임 연구원인 던컨 캠벨은 보안 및 감시와 관련된 미해결 문제의 예로 _NSAKEY 논란을 언급했다.

또한, 니코 반 소머런 박사는 윈도우 2000에서 세 번째 키를 발견했는데, 그는 이 키가 합법적인 목적을 가지고 있는지 의구심을 표하며 "더 수상해 보인다"고 선언했다.

마이크로소프트의 반응

마이크로소프트는 _NSAKEY에 대한 백도어 추측을 부인하며 "마이크로소프트는 정부가 제안한 다양한 키 에스크로 제안을 일관되게 반대해 왔기 때문에 이러한 추측은 아이러니하다"고 말했다. 마이크로소프트에 따르면, 해당 키의 심볼이 "_NSAKEY"였던 이유는 NSA가 미국 암호 기술 수출 통제의 검토 기관이었기 때문이다.

마이크로소프트의 기업 프라이버시 책임자인 리처드 퍼셀은 발표 후 캠벨에게 다가가 _NSAKEY에 대한 혼란과 의심을 해소하고 싶다는 의사를 밝혔다. 컨퍼런스 직후, 마이크로소프트 보안 대응 센터의 스콧 컬프는 캠벨에게 연락하여 질문에 답변하겠다고 제안했다. 그들의 서신 왕래는 정중하게 시작되었으나 곧 경색되었다. 캠벨은 컬프가 회피적이라고 느꼈고, 컬프는 캠벨이 이미 답변한 질문을 적대적으로 반복한다고 느꼈다. 2000년 4월 28일, 컬프는 "우리는 확실히 이 논의의 끝에 도달했다... [이 논의는] 빠르게 음모론의 영역으로 치닫고 있다"고 언급했다.

마이크로소프트는 세 번째 키는 윈도우 2000의 베타 빌드에만 존재하며, 그 목적은 암호화 서비스 공급자를 서명하기 위한 것이라고 주장했다.

추가 기술 정보

모질라의 암호화 관련 일반 질문 페이지는 마이크로소프트가 CSP를 서명하는 방식을 설명한다.

API를 통해 암호화 기능을 호출하는 소프트웨어에 대해 수출 라이선스를 취득하는 것은 특정 상황에서 실제로 가능하다. 예를 들어, 마이크로소프트의 마이크로소프트 암호화 API(CryptoAPI) 사양 구현은 미국 밖의 제3자를 포함한 제3자가 암호화 기능을 구현하는 별도의 모듈("암호화 서비스 공급자" 또는 CSP)을 추가할 수 있는 API를 구현함에도 불구하고 미국으로부터의 수출 승인을 받았다. 이러한 수출 승인은 아마도 다음의 이유로 가능했을 것이다: a) CryptoAPI 구현은 제3자 CSP가 마이크로소프트에 의해 디지털 서명될 것을 요구하며, 그렇게 서명되지 않은 CSP를 호출하려는 시도를 거부함. b) 이 서명 프로세스를 통해 마이크로소프트는 관련 미국 수출 통제 규정 준수를 보장할 수 있음(예: 미국 밖에서 개발된 강력한 암호화를 구현하는 CSP는 서명하지 않을 것으로 추정됨). c) 마이크로소프트의 CryptoAPI 구현은 실행 가능한 형태로만 제공되므로, CSP 디지털 서명 검사를 비활성화하기 위한 사용자 변조에 대해 합리적으로 저항력이 있는 것으로 간주됨.

페르난데스에 따르면 _NSAKEY를 교체하는 것이 가능하다. 암호화 모듈을 로드할 때 crypto_verify 함수는 먼저 _KEY를 사용하여 모듈을 확인하고, 그 다음 _NSAKEY를 사용한다. 윈도우의 어떤 암호화 모듈도 _NSAKEY로 서명되지 않았기 때문에 이 키는 전혀 사용되지 않는다. 이를 다른 키로 교체하면 미국 이외의 기업들이 마이크로소프트나 NSA의 승인 없이도 윈도우에 자사의 암호화 서비스를 설치할 수 있다.

추가 추측

마이크로소프트는 두 번째 키가 주 비밀 키를 분실할 가능성에 대비한 백업용으로 존재한다고 밝혔다. 페르난데스는 이 설명을 의심하며, 비밀 키 분실에 대비하는 일반적으로 인정되는 방법은 비밀 키를 여러 조각으로 나누어 경영진에게 배포하는 비밀 분할(secret splitting)이라고 지적했다. 그는 이것이 두 개의 키를 사용하는 것보다 훨씬 더 강력할 것이라고 말했다. 만약 두 번째 키마저 분실된다면 마이크로소프트는 전 세계의 모든 윈도우 사본과 지금까지 서명한 모든 암호화 모듈을 패치하거나 업그레이드해야 할 것이기 때문이다.

반면에 마이크로소프트가 키 분실의 결과를 고려하지 않고 비밀 분할을 사용하지 않은 상태로 첫 번째 키를 생성했고(키 생성 후 보호를 약화시킬 수 없는 보안 하드웨어 내에서 생성), 검토 과정의 일환으로 NSA가 이 문제를 지적했다면, 마이크로소프트가 두 번째 키로 체계를 약화시킨 이유와 새 키를 _NSAKEY라고 부른 이유를 설명할 수 있을 것이다. (두 번째 키는 비밀 분할을 사용하여 백업될 수 있으므로 두 키를 모두 잃어버리는 것은 문제가 되지 않아야 한다.) 또 다른 가능성은 마이크로소프트가 BIS의 EAR을 준수하면서도 미국 밖에서 암호화 모듈에 서명할 수 있도록 두 번째 키를 포함했을 가능성이다. 암호화 모듈을 여러 위치에서 서명해야 한다면, 여러 키를 사용하는 것이 합리적인 접근 방식이다. 그러나 _NSAKEY에 의해 서명된 암호화 모듈은 발견된 적이 없으며, 마이크로소프트는 다른 인증 기관이 존재한다는 것을 부인한다.

브루스 슈나이어는 NSA가 윈도우에 임의의 백도어가 있는 CSP를 로드할 수 있도록 키를 넣는다는 식의 우려는 근거가 없다고 믿는다. 그는 회사 전체에 보이는 디버그 심볼에 "NSAKEY"라는 이름을 붙이는 것은 고사하고, 추가 키를 사용하지 않고도 윈도우에 백도어를 설치할 수 있는 더 쉬운 방법들이 있다고 주장한다. NSA는 그냥 주 키를 요구하면 그만이기 때문이다. CryptoAPI 또한 피해자가 NSA가 제공한 실행 파일을 실행해야 하므로 부적절한 진입점이다.

키 값

두 키 모두 RSA 키이며, e 값은 표준 선택인 65537과 같다.

_KEY의 n 값은 다음과 같다:

b273e277a9c375c70bb7493e52b0b36962e976626ad609ba31be6accac12f1f3da6c18d96951820c457c7b4c4893bd149de279a39f6ec926d3544db3491fa2e9af1bf8260b3b0fbadd69cbd77b28012925711b17c0b877eaf7da9d02dd5f8572854e5c90e9b10cfbaeaf8b8fe1df5047bc18829a531499bbf49e8021346b5095

_NSAKEY의 n 값은 다음과 같다:

ba8e15fee3cd160fb47cf93e2b4d842615af23f0659264d81edc35a27d3aa450890a227b561da401ff3908771d243f6eeb4f9e351976e90f07fd22cd099ccd71e85b97f5439adb172d32d71cb66c26c5b188a3e11790ed01eb31bf27bc667b396fd8283097d8b3869cc7511a3496e829a32bbad6d2f7aa7e8ca9805d51682d1f

PGP 키

1999년 9월, 익명의 연구원이 주 키와 _NSAKEY를 모두 PGP 호환 형식으로 리버스 엔지니어링하여 키 서버에 게시했다.

주 키 (_KEY)

Type Bits/KeyID Date User ID
pub 1024/346B5095 1999/09/06 Microsoft's CAPI key <postmaster@microsoft.com>

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i

mQCPAzfTc8YAAAEEALJz4nepw3XHC7dJPlKws2li6XZiatYJujG+asysEvHz2mwY
2WlRggxFfHtMSJO9FJ3ieaOfbskm01RNs0kfoumvG/gmCzsPut1py9d7KAEpJXEb
F8C4d+r32p0C3V+FcoVOXJDpsQz7rq+Lj+HfUEe8GIKaUxSZu/SegCE0a1CVABEB
AAG0L01pY3Jvc29mdCdzIENBUEkga2V5IDxwb3N0bWFzdGVyQG1pY3Jvc29mdC5j
b20+iQEVAwUQN9Nz5j57yqgoskVRAQFr/gf8DGm1hAxWBmx/0bl4m0metM+IM39J
yI5mub0ie1HRLExP7lVJezBTyRryV3tDv6U3OIP+KZDthdXb0fmGU5z+wHt34Uzu
xl6Q7m7oB76SKfNaWgosZxqkE5YQrXXGsn3oVZhV6yBALekWtsdVaSmG8+IJNx+n
NvMTYRUz+MdrRFcEFDhFntblI8NlQenlX6CcnnfOkdR7ZKyPbVoSXW/Z6q7U9REJ
TSjBT0swYbHX+3EVt8n2nwxWb2ouNmnm9H2gYfXHikhXrwtjK2aG/3J7k6EVxS+m
Rp+crFOB32sTO1ib2sr7GY7CZUwOpDqRxo8KmQZyhaZqz1x6myurXyw3Tg==
=ms8C
-----END PGP PUBLIC KEY BLOCK-----

보조 키 (_NSAKEY 및 _KEY2)

Type Bits/KeyID Date User ID
pub 1024/51682D1F 1999/09/06 NSA's Microsoft CAPI key <postmaster@nsa.gov>

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i

mQCPAzfTdH0AAAEEALqOFf7jzRYPtHz5PitNhCYVryPwZZJk2B7cNaJ9OqRQiQoi
e1YdpAH/OQh3HSQ/butPnjUZdukPB/0izQmczXHoW5f1Q5rbFy0y1xy2bCbFsYij
4ReQ7QHrMb8nvGZ7OW/YKDCX2LOGnMdRGjSW6CmjK7rW0veqfoypgF1RaC0fABEB
AAG0LU5TQSdzIE1pY3Jvc29mdCBDQVBJIGtleSA8cG9zdG1hc3RlckBuc2EuZ292
PokBFQMFEDfTdJE+e8qoKLJFUQEBHnsH/ihUe7oq6DhU1dJjvXWcYw6p1iW+0euR
YfZjwpzPotQ8m5rC7FrJDUbgqQjoFDr++zN9kD9bjNPVUx/ZjCvSFTNu/5X1qn1r
it7IHU/6Aem1h4Bs6KE5MPpjKRxRkqQjbW4f0cgXg6+LV+V9cNMylZHRef3PZCQa
5DOI5crQ0IWyjQCt9br07BL9C3X5WHNNRsRIr9WiVfPK8eyxhNYl/NiH2GzXYbNe
UWjaS2KuJNVvozjxGymcnNTwJltZK4RLZxo05FW2InJbtEfMc+m823vVltm9l/f+
n2iYBAaDs6I/0v2AcVKNy19Cjncc3wQZkaiIYqfPZL19kT8vDNGi9uE=
=PhHT
-----END PGP PUBLIC KEY BLOCK-----

같이 보기

각주

  1. ↑ Chappell, Geoff (1999년 9월 12일). “CSP Signatures”. 2006년 5월 4일에 원본 문서에서 보존된 문서.
  2. 1 2 Fernandes, Andrew (1999년 8월 31일). “Microsoft, the NSA, and You”. 《cryptonym.com》. Cryptonym. 2000년 6월 17일에 원본 문서에서 보존된 문서. 2005년 10월 26일에 확인함.
  3. ↑ “NSA key to Windows: an open question”. 《CNN Online》. Cable News Network. 1999년 9월 5일. 2015년 10월 5일에 원본 문서에서 보존된 문서.
  4. ↑ Campbell, Duncan (1999년 1월 4일). “How NSA access was built into Windows”. 《Heise Online》. Heise Medien.
  5. ↑ “Microsoft Says Speculation About Security and NSA Is "Inaccurate and Unfounded"”. 《News Center》. Redmond, WA: 마이크로소프트. 1999년 9월 3일. 2012년 10월 24일에 원본 문서에서 보존된 문서.
  6. 1 2 “There is no "Back Door" in Windows”. Microsoft. 1999년 9월 7일. 2000년 5월 20일에 원본 문서에서 보존된 문서. 2007년 1월 7일에 확인함.
  7. ↑ “Windows NSAKEY Controversy”. Rice University.
  8. ↑ “Mozilla Crypto FAQ”. 1999년 4월 22일에 원본 문서에서 보존된 문서. 2020년 4월 12일에 확인함.
  9. ↑ Schneier, Bruce (1999년 9월 15일). “NSA Key in Microsoft Crypto API?”. Counterpane. 2007년 1월 7일에 확인함.
  10. ↑ “DomainKeys Identified Mail (DKIM) Signatures”. 《IETF》. 1970년 1월 1일. 2024년 12월 12일에 확인함.
  11. ↑ “The reverse-engineered keys”. Cypherspace. 1999년 9월 6일. 2007년 1월 7일에 확인함.