_NSAKEY

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

_NSAKEY est le nom d'une variable découverte en août 1999 dans le système d'exploitation Windows NT 4 (SP5) de Microsoft. Cette version fut diffusée sans que les informations destinées au débugage soient enlevées.

La variable découverte par Andrew D. Fernandes de Cryptonym Corporation contenait une clé publique de 1024 bits. La nouvelle provoqua un tollé général et l'apparition de diverses rumeurs. L'hypothèse intuitive était que la National Security Agency disposait de la clé privée correspondant à la clé publique du système d'exploitation, et visait donc à transmettre des informations depuis tous les postes équipés de cet OS de sorte que seule la NSA puisse ensuite les utiliser. Cette hypothèse implique un accord secret entre la NSA et Microsoft dans le but d'espionner les utilisateurs.

Contexte[modifier | modifier le code]

Toute suite cryptographique intégrée au sein des systèmes d'exploitation de Microsoft nécessite d'être signée numériquement. Cette procédure facilite les démarches auprès de l'administration américaine chargée de vérifier les produits exportés, la EAR (Export Administration Regulations). Cette entité fait partie du Département du Commerce et comprend le BXA (Bureau of Export Administration).

L'utilisation de deux clés par Microsoft était déjà connue. Les deux pouvant produire des signatures valides. La première clé était contenue dans la variable _KEY, Fernandes a découvert la seconde.

Réaction de Microsoft[modifier | modifier le code]

Microsoft réfuta les accusations : « (...) ce rapport est inexact et infondé. La clé en question est une clé de Microsoft. Elle est maintenue et (la clé secrète) conservée à l'abri. Nous n'avons pas partagé cette clé avec la NSA ou toute autre tierce partie. (...) »[réf. nécessaire]. Le symbole _NSAKEY avait été attribué en raison des expertises techniques et le contrôle à l'exportation opérés par la NSA. La clé était également compatible avec les lois d'exportation des États-Unis.

Mais certaines déclarations de Microsoft, alors que la discussion battait son plein, aggravèrent encore plus la paranoïa.

La conférence The Computers, Freedom and Privacy 2000 eut lieu du 4 au 7 avril 2000 à Toronto. Lors d'une présentation, Duncan Campbell, journaliste et Senior Research Fellow au sein du Electronic Privacy Information Center (EPIC), mentionna que la controverse liée à la _NSAKEY était un exemple frappant des problèmes liés à la sécurité et la surveillance.

Richard Purcell, directeur de la section Corporate Privacy de Microsoft, parla avec Campbell après sa présentation pour éclaircir cette polémique. Immédiatement après la conférence, Scott Culp du Security Response Center de Microsoft contacta Campbell et lui proposa de répondre à ses questions. Si leurs échanges furent courtois au début, la discussion s'envenima rapidement. Campbell affirma que Culp était évasif et Culp de son côté déclara, que dans un dessein hostile, Campbell ne cessait de poser des questions auxquelles il avait déjà répondu.

Le 28 avril 2000, Culp déclara que « nous avons sans doute atteint la fin de cette discussion (...) qui est rapidement en train de s'enfoncer dans le royaume de la conspiration ». Les autres interrogations de Campbell restèrent sans réponses.

Autres théories[modifier | modifier le code]

Après une polémique avec divers expertises cryptographiques, plusieurs conclusions furent avancées. Certains observateurs, dont Fernandes, doutaient que le BXA imposait une sauvegarde spécifique des clés. Cependant, aucun des partisans de cette thèse n'estimait avoir la compétence nécessaire pour formellement la prouver.

Microsoft insista pour que la seconde clé soit présentée comme une sauvegarde. Si la première clé secrète venait à être perdue, Microsoft pourrait toujours travailler avec l'autre paire. Fernandes et Bruce Schneier firent part de leurs doutes quant à la pertinence de cette explication. Pour eux, le meilleur moyen de conserver une clé secrète consiste à la diviser en plusieurs morceaux qui seraient distribués à des personnes de confiance. Une telle solution serait bien plus robuste que d'utiliser deux clés. Si la seconde clé avait été perdue, Microsoft aurait dû « patcher » ou mettre à jour l'ensemble des copies de Windows dans le monde, de même que tous les modules que l'entreprise aurait pu signer.

Une autre conclusion affirme que la seconde clé était destinée à des signatures en dehors des États-Unis, tout en restant compatible avec les réglements du BXA. Si les modules cryptographiques devaient être signés en plusieurs endroits, l'utilisation de plusieurs clés semblait plus logique. Cependant, aucun module cryptographique ne semble avoir été signé par la _NSAKEY et Microsoft a démenti qu'une autre autorité de certification existait.

Une troisième possibilité concernerait la NSA et d'autres agences gouvernementales qui, pour pouvoir signer leurs propres modules cryptographiques, utiliseraient la clé secrète. Ces modules avec des algorithmes classifiés seraient utilisés au sein des agences sans être transmis à Microsoft. Une telle possibilité permettrait de facto à la NSA de signer des modules qui pourraient rendre Windows plus vulnérable. On a toutefois fait remarquer qu'il y avait des moyens plus simples pour mettre à mal une installation de Windows sans passer par l'API de cryptographie.

Microsoft a affirmé que la NSA ne possédait pas la clé secrète correspondant à la _NSAKEY. La clé est à ce jour encore présente dans Windows mais elle a été renommée en « _KEY2 ».

Les clés au format PGP[modifier | modifier le code]

En septembre 1999, un chercheur anonyme a appliqué de la rétro-ingénierie sur les clés pour obtenir les données équivalentes au format PGP et a publié le résultat sur un serveur de clés :

Clé principale[modifier | modifier le code]

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-----

Clé secondaire (_NSAKEY)[modifier | modifier le code]

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-----

Références[modifier | modifier le code]