_NSAKEY fue un nombre de variable descubierto en Windows NT 4 SP5 en 1999 por Andrew D. Fernandes de Cryptonym Corporation. La variable contenía una clave pública de 1024 bits; dichas claves se utilizan en criptografía de clave pública para cifrado y autenticación . Sin embargo, debido al nombre, se especuló que la clave permitiría a la Agencia de Seguridad Nacional de los Estados Unidos (NSA) subvertir la seguridad de cualquier usuario de Windows. Microsoft negó la especulación y dijo que el nombre de la clave provenía del hecho de que la NSA era la autoridad de revisión técnica para los controles de exportación de criptografía de los Estados Unidos .
Microsoft exige que todos los paquetes de criptografía que interoperan con Microsoft Windows tengan una firma digital RSA . Dado que solo los paquetes de criptografía aprobados por Microsoft pueden enviarse con Windows, es posible mantener copias de exportación de este sistema operativo de conformidad con las Regulaciones de Administración de Exportaciones (EAR), que son aplicadas por la Oficina de Industria y Seguridad (BIS). [1]
Ya se sabía que Microsoft utilizaba dos claves, una principal y otra de repuesto, cualquiera de las cuales puede crear firmas válidas. Al lanzar el Service Pack 5 para Windows NT 4 , Microsoft se olvidó de eliminar los símbolos de depuración en ADVAPI32.DLL , una biblioteca utilizada para funciones avanzadas de Windows como Registro y Seguridad. Andrew Fernandes, científico jefe de Cryptonym, encontró la clave principal almacenada en la variable _KEY y la segunda clave estaba etiquetada como _NSAKEY . [2] Fernandes publicó su descubrimiento, lo que desencadenó una oleada de especulaciones y teorías conspirativas , incluida la posibilidad de que la segunda clave fuera propiedad de la Agencia de Seguridad Nacional de los Estados Unidos (NSA) y permitiera a la agencia de inteligencia subvertir la seguridad de cualquier usuario de Windows. [3]
Durante una presentación en la conferencia Computers, Freedom and Privacy 2000 (CFP2000), Duncan Campbell , investigador principal del Electronic Privacy Information Center (EPIC), mencionó la controversia NSAKEY como un ejemplo de un problema pendiente relacionado con la seguridad y la vigilancia. [ cita requerida ]
Además, el Dr. Nicko van Someren encontró una tercera clave en Windows 2000, de la que dudaba que tuviera un propósito legítimo y declaró que "parece más sospechosa". [4]
Microsoft negó las especulaciones sobre la puerta trasera en _NSAKEY y dijo que "Esta especulación es irónica ya que Microsoft se ha opuesto consistentemente a las diversas propuestas de depósito de claves sugeridas por el gobierno". Según Microsoft, el símbolo de la clave era " _NSAKEY " porque la NSA era la autoridad de revisión técnica para los controles de exportación de criptografía de EE. UU. , y la clave aseguraba el cumplimiento de las leyes de exportación de EE. UU. [5] [6]
Richard Purcell, director de privacidad corporativa de Microsoft, se acercó a Campbell después de su presentación y expresó su deseo de aclarar la confusión y las dudas sobre _NSAKEY . Inmediatamente después de la conferencia, Scott Culp, del Centro de Respuesta de Seguridad de Microsoft, se puso en contacto con Campbell y se ofreció a responder a sus preguntas. Su correspondencia comenzó cordialmente, pero pronto se volvió tensa; Campbell aparentemente sintió que Culp estaba siendo evasivo y Culp aparentemente sintió que Campbell estaba repitiendo hostilmente preguntas que ya había respondido. El 28 de abril de 2000, Culp declaró que "definitivamente hemos llegado al final de esta discusión... [que] está desembocando rápidamente en el reino de la teoría de la conspiración". [7]
Microsoft afirmó que la tercera clave sólo estaba en las versiones beta de Windows 2000 y que su propósito era firmar proveedores de servicios criptográficos . [6]
La página de Mozilla sobre preguntas comunes sobre criptografía describe cómo Microsoft firma los CSP:
De hecho, es posible, en determinadas circunstancias, obtener una licencia de exportación para software que invoque funciones criptográficas a través de una API. Por ejemplo, la implementación de Microsoft de la especificación Microsoft Cryptographic API (CryptoAPI) fue aprobada para su exportación desde los EE. UU., a pesar de que implementa una API mediante la cual terceros, incluidos terceros fuera de los EE. UU., pueden agregar módulos separados ("Proveedores de servicios criptográficos" o CSP) que implementan funcionalidad criptográfica. Esta aprobación de exportación fue posible presumiblemente porque a) la implementación de CryptoAPI requiere que los CSP de terceros estén firmados digitalmente por Microsoft y rechaza los intentos de llamar a CSP que no estén firmados de esa manera; b) a través de este proceso de firma, Microsoft puede garantizar el cumplimiento de las regulaciones de control de exportación pertinentes de los EE. UU. (por ejemplo, presumiblemente no firmarían un CSP desarrollado fuera de los EE. UU. que implemente criptografía fuerte); y c) la implementación de CryptoAPI de Microsoft está disponible solo en forma ejecutable y, por lo tanto, se presume que es razonablemente resistente a la manipulación por parte del usuario para desactivar la verificación de firma digital del CSP. [8]
Fue posible eliminar el segundo _NSAKEY: al cargar un módulo criptográfico, el crypto_verifyprimero intenta usar _KEYpara verificar el módulo y luego pasa a _NSAKEYsi la primera clave falla. Dado que ningún módulo criptográfico conocido en Windows está firmado con _NSAKEY, nunca se utiliza. Reemplazar la clave con una clave diferente permite a las empresas no estadounidenses instalar sus propios servicios criptográficos "fuertes" en Windows sin la aprobación de Microsoft o la NSA. [2]
Microsoft afirmó que la segunda clave está presente como respaldo para protegerse contra la posibilidad de perder la clave secreta principal. Fernandes duda de esta explicación, señalando que la forma generalmente aceptada de protegerse contra la pérdida de una clave secreta es la división secreta , que dividiría la clave en varias partes diferentes, que luego se distribuirían entre la alta dirección. Afirmó que esto sería mucho más robusto que usar dos claves; si también se pierde la segunda clave, Microsoft tendría que parchear o actualizar cada copia de Windows en el mundo, así como cada módulo criptográfico que haya firmado. [ cita requerida ]
Por otra parte, si Microsoft no pensó en las consecuencias de la pérdida de claves y creó una primera clave sin utilizar la división secreta (y lo hizo en un hardware seguro que no permite que la protección se debilite después de la generación de claves), y la NSA señaló este problema como parte del proceso de revisión, podría explicar por qué Microsoft debilitó su esquema con una segunda clave y por qué la nueva se llamó _NSAKEY . (La segunda clave podría respaldarse mediante la división secreta, por lo que perder ambas claves no debería ser un problema). Otra posibilidad es que Microsoft incluyera una segunda clave para poder firmar módulos criptográficos fuera de los Estados Unidos, sin dejar de cumplir con la EAR de la BIS. Si los módulos criptográficos se firmaran en múltiples ubicaciones, el uso de múltiples claves es un enfoque razonable. Sin embargo, nunca se ha encontrado ningún módulo criptográfico firmado por _NSAKEY , y Microsoft niega que exista otra autoridad de certificación. [ cita requerida ]
Bruce Schneier cree que el tipo de preocupación antes mencionado, es decir, que la NSA coloque una clave en Windows para que pueda cargar CSP arbitrarios con puerta trasera, es infundada. Sostiene que hay formas más fáciles de introducir una puerta trasera en Windows que no implican el uso de una clave adicional, y mucho menos una llamada "NSAKEY" en símbolos de depuración visibles para toda la empresa: la NSA podría simplemente pedir la clave principal. La API de cifrado también es un punto de entrada deficiente, ya que requiere que la víctima ejecute un ejecutable proporcionado por la NSA. [9]
En septiembre de 1999, un investigador anónimo realizó ingeniería inversa de la clave principal y de la _NSAKEY en un formato compatible con PGP y las publicó en servidores de claves . [10]
Tipo Bits/KeyID Fecha ID de usuario pub 1024/346B5095 1999/09/06 Clave CAPI de Microsoft <[email protected]> -----INICIO DEL BLOQUE DE CLAVE PÚBLICA PGP----- Versión: 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 -----FIN DEL BLOQUE DE CLAVE PÚBLICA PGP-----
Tipo Bits/KeyID Fecha ID de usuario pub 1024/51682D1F 1999/09/06 Clave CAPI de Microsoft de la NSA <[email protected]> -----INICIO DEL BLOQUE DE CLAVE PÚBLICA PGP----- Versión: 2.6.3i mQCPAzfTdH0AAAEEALqOFf7jzRYPtHz5PitNhCYVryPwZZJk2B7cNaJ9OqRQiQoi e1YdpAH/OQh3HSQ/peroPnjUZdukPB/0izQmczXHoW5f1Q5rbFy0y1xy2bCbFsYij 4ReQ7QHrMb8nvGZ7OW/YKDCX2LOGnMdRGjSW6CmjK7rW0veqfoypgF1RaC0fABEB AAG0LU5TQSdzIE1pY3Jvc29mdCBDQVBJIGtleSA8cG9zdG1hc3RlckBuc2EuZ292 PokBFQMFEDfTdJE+e8qoKLJFUQEBHnsH/ihUe7oq6DhU1dJjvXWcYw6p1iW+0euR YfZjwpzPotQ8m5rC7FrJDUbgqQjoFDr++zN9kD9bjNPVUx/ZjCvSFTNu/5X1qn1r es7IHU/6Aem1h4Bs6KE5MPpjKRxRkqQjbW4f0cgXg6+LV+V9cNMylZHRef3PZCQa 5DOI5crQ0IWyjQCt9br07BL9C3X5WHNNRsRIr9WiVfPK8eyxhNYl/NiH2GzXYbNe UWjaS2KuJNVvozjxGymcnNTwJltZK4RLZxo05FW2InJbtEfMc+m823vVltm9l/f+ n2iYBAaDs6I/0v2AcVKNy19Cjncc3wQZkaiIYqfPZL19kT8vDNGi9uE= =PhHT -----FIN DEL BLOQUE DE CLAVE PÚBLICA PGP-----