# NSAKEY

_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ébogage 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

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 : une principale et une de secours, les deux pouvant produire des signatures valides. La première clé était contenue dans la variable _KEY, Fernandes a découvert la seconde, _NSAKEY, dans la DLL ADVAPI32 utilisée pour des fonctions avancées relative à la base de registre.

## Réaction de Microsoft

Microsoft réfuta les accusations d'utilisation de _NSAKEY comme porte dérobée : « (...) 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. (...) ». Le symbole _NSAKEY avait été attribué en raison des expertises techniques et du 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 : lors de la conférence The Computers, Freedom and Privacy 2000 du 4 au 7 avril 2000 à Toronto, Duncan Campbell, journaliste et Senior Research Fellow au sein du Electronic Privacy Information Center (EPIC), mentionna lors d'une présentation que la controverse liée à la _NSAKEY était un exemple frappant des problèmes liés à la sécurité et la surveillance, ce à la suite de quoi 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 « 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éponse.
Par ailleurs, l'existence d'une troisième clé dans Windows 2000 fut révélée au grand jour par le docteur Nicko van Someren (en), qui déclara douter de son utilité réelle, précisant que celle-ci avait l'air "louche".

## Autres théories

Après une polémique et diverses expertises cryptographiques, plusieurs conclusions furent avancées. Certains observateurs, dont Fernandes, doutaient que le BXA imposât 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

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 :