nsakey - Wikilingue - Encydia
 |
Título correcto : « _NSAKEY » Debido a limitaciones técnicas, la typographie deseable del título no ha podido ser restituida correctamente.
|
_NSAKEY Es el nombre de una variable descubierta en agosto 1999 en el sistema de aprovechamiento Windows NT 4 (SP5) de Microsoft . Esta versión fue difundida sin que las informaciones destinadas al débugage sean quitadas.
La variable descubierta por Andrew D. Fernandes De Cryptonym Corporación contenía una llave pública de 1024 bits. La noticia provocó un tollé general y la aparición de diversos rumores con relación a una eventual conspiración gubernamental. Si la NSA había estado efectivamente en posesión de la llave secreta que corresponde en la llave presente en Windows NT, él habría sido posible de cifrar datos procedentes de los usuarios y, con la complicidad de Microsoft, de recuperar estas informaciones.
Sumario |
Contexto
Toda continuación cryptographique integrada al seno de los sistemas de aprovechamiento de Microsoft necesita de ser firmada numériquement. Este procedimiento facilita los transcursos cerca de la administración estadounidense cargada de verificar los productos exportés, la EAR (Export Administración Regulaciones). Esta entidad formada parte del Departamento del Comercio y comprende el BXA (Despacho of Export Administración).
La utilización de dos llaves por Microsoft era conocida ya. Ambos que pueden producir firmas validas. La primera llave era contenida en la variable _KEY, Fernandes ha descubierto la segunda.
Reacción de Microsoft
Microsoft réfuta Las acusaciones : « (...) Este informe es inexact e infondé. La llave en cuestión es una llave de Microsoft. Es mantenida y (la llave secreta) conservada al abrigo. No hemos compartido esta llave con la NSA o toda otra tierce parte. (...) ». El símbolo _NSAKEY había sido atribuido debido a las valoraciones técnicas y el control en la exportación operada por la NSA. La llave era igualmente compatible con las leyes de exportación de Estados Unidos .
Pero ciertas declaraciones de Microsoft, mientras que la discusión batía su lleno, agravaron todavía más la paranoia .
La conferencia The Computers, Freedom and Privacy 2000 tuvo lugar del 4 al 7 de abril de 2000 en Toronto. Durante una presentación, Duncan Campbell, periodista y Senior Research Fellow al seno del Electronic Privacy Información Center (EPIC), mencionó que la controversia relacionada a la _NSAKEY era un ejemplo asombroso de los problemas relacionados a la seguridad y la vigilancia.
Richard Purcell, director de la sección Corporate Privacy de Microsoft, habló con Campbell después de su presentación para aclarar esta polémica. Inmediatamente después de la conferencia, Scott Culp del Security Response Center de Microsoft contactó Campbell y propuso de responder en sus cuestiones. Si sus intercambios fueron courtois al principio, la discusión se envenima rápidamente. Campbell afirmó que Culp era évasif y Culp de su lado declaró, que en un propósito hostil, Campbell no cesaba de plantear cuestiones a las cuales había respondido ya.
El 28 de abril de 2000, Culp declaró que « tenemos sin duda alcanzada el final de esta discusión (...) Que es rápidamente en tren de adentrarse en el reino de la conspiración ». Las demás interrogaciones de Campbell quedaron sin respuestas.
Otras teorías
Después de una polémica con varias valoraciones cryptographiques, varias conclusiones fueron adelantadas. Ciertos observadores, cuyos Fernandes, dudaban que el BXA imponía una salvaguarda específica de las llaves. No obstante, ningún de los partidarios de esta tesis no estimaba haber la competencia necesaria para formalmente probarla.
Microsoft Insistió para que la segunda llave sea presentada como una salvaguarda. Si la primera llave secreta venía a ser perdida, Microsoft podría siempre trabajar con el otro par. Fernandes Y Bruce Schneier hicieron parte de sus dudas con respecto a la idoneidad de esta explicación. Para ellos, el mejor medio de conservar una llave secreta consiste en dividirla en varios trozos que serían distribuidos a personas de confianza. Una tal solución sería bien más robuste que de utilizar dos llaves. Si la segunda llave había sido perdida, Microsoft habría tenido que « patcher » o actualizar el conjunto de las copias de Windows en el mundo, al igual que todos los módulos que la empresa habría podido firmar.
Otra conclusión afirma que la segunda llave era destinada a firmas fuera de Estados Unidos, todo quedando compatible con los réglements del BXA. Si los módulos cryptographiques tenían que ser firmados en varios sitios, la utilización de varias llaves parecía más lógica. No obstante, ningún módulo cryptographique no parece haber sido firmado por la _NSAKEY y Microsoft ha desmentido que otra autoridad de certificación existía.
Una tercera posibilidad implicaría la NSA y otras agencias gubernamentales que, para poder firmar sus propios módulos cryptographiques, utilizarían la llave secreta. Estos módulos con de los algorithmes classifiés serían utilizados en el seno de las agencias sin ser transmitido a Microsoft. Una tal posibilidad permitiría facto a la NSA de firmar módulos que podrían devolver Windows más vulnerable. Se tiene sin embargo hecho constar que había medios más meros para poner a mal una instalación de Windows sin pasar por la API de cryptographie.
Microsoft Ha afirmado que la NSA no poseía la llave secreta corresponde a la _NSAKEY. La llave es en este día todavía presente en Windows pero ha sido afamada « _KEY2 ».
Las llaves en el formato PGP
En septiembre 1999, un investigador anónimo ha aplicado de la rétro-ingeniería sobre las llaves para obtener los datos equivalentes en el formato PGP y ha publicado el resultado sobre un servidor de llaves :
Llave principal
Tipo Bits/KeyID Data Usar ID pub 1024/346B5095 1999/09/06 Microsoft's CAPI key <postmaster@microsoft.com>
-----BEGIN PGP PÚBLICO KEY BLOCK----- Versión: 2.6.3i mQCPAzfTc8YAAAEEALJz4nepw3XHC7dJPlKws2li6XZiatYJujG+asysEvHz2mwY 2WlRggxFfHtMSJO9FJ3ieaOfbskm01RNs0kfoumvG/gmCzsPut1py9d7KAEpJXEb F8C4d+r32p0C3V+FcoVOXJDpsQz7rq+Lj+HfUEe8GIKaUxSZu/SegCE0tiene1CVABEB AAG0L01pY3Jvc29mdCdzIENBUEkga2V5IDxwb3N0bWFzdGVyQG1pY3Jvc29mdC5j b20+iQEVAwUQN9Nz5j57yqgoskVRAQFr/gf8DGm1hAxWBmx/0bl4m0metM+IM39J yI5mub0ie1HRLExP7lVJezBTyRryV3tDv6U3OIP+KZDthdXb0fmGU5z+wHt34Uzu xl6Q7m7oB76SKfNaWgosZxqkE5YQrXXGsn3oVZhV6yBALekWtsdVaSmG8+IJNx+n NvMTYRUz+MdrRFcEFDhFntblI8NlQenlX6CcnnfOkdR7ZKyPbVoSXW/Z6q7U9REJ TSjBT0swYbHX+3eVt8n2nwxWb2ouNmnm9H2gYfXHikhXrwtjK2aG/3J7k6EVxS+m Rp+crFOB32sTO1ib2sr7GY7CZUwOpDqRxo8KmQZyhaZqz1x6myurXyw3Tg== =ms8C -----END PGP PÚBLICO KEY BLOCK-----
Llave secundaria (_NSAKEY)
Tipo Bits/KeyID Data Usar ID pub 1024/51682d1F 1999/09/06 NSA's Microsoft CAPI key <postmaster@nsa.gov> -----BEGIN PGP PÚBLICO KEY BLOCK----- Versión: 2.6.3i mQCPAzfTdH0AAAEEALqOFf7jzRYPtHz5PitNhCYVryPwZZJk2B7cNaJ9OqRQiQoi e1YdpAH/OQh3HSQ/butPnjUZdukPB/0izQmczXHoW5f1Q5rbFy01xy2bCbFsYij 4ReQ7QHrMb8nvGZ7OW/YKDCX2LOGnMdRGjSW6CmjK7rW0veqfoypgF1RaC0fABEB AAG0LEÍDO5TQSdzIE1pY3Jvc29mdCBDQVBJIGtleSA8cG9zdG1hc3RlckBuc2EuZ292 PokBFQMFEDfTdJE+e8qoKLJFUQEBHnsH/ihUe7oq6DhU1dJjvXWcYw6p1iW+0euR YfZjwpzPotQ8m5rC7FrJDUbgqQjoFDr++zN9kD9bjNPVUx/ZjCvSFTNu/5X1qn1r it7IHU/6Aem1h4Bs6KE5MPpjKRxRkqQjbW4f0cgXg6+LV+V9cNMylZHRef3PZCQa 5DOI5crQ0IWyjQCt9br07BL9C3X5WHNNRsRIr9WiVfPK8eyxhNYl/NiH2GzXYbNe UWjaS2KuJNVvozjxGymcnNTwJltZK4RLZxo05FW2InJbtEfMc+m823vVltm9l/f+ n2iYBAaDs6I/0v2AcVKNy19Cjncc3wQZkaiIYqfPZL19kT8vDNGi9uE= =PhHT -----END PGP PÚBLICO KEY BLOCK-----
Referencias
- () Correspondencia entre Culp y Campbell
- () Análisis de Bruce Schneier
- () Las llaves después de rétro-ingeniería
Portal de la cryptologie 
Portal de la seguridad informática
