_NSAKEY

_NSAKEY est le nom d'une variable découverte en 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[1].

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. (...) »[réf. nécessaire]. 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 à 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 , 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"[2].

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 :

Clé principale

 
 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)

 
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
  1. « CNN - NSA key to Windows: an open question - September 3, 1999 », sur edition.cnn.com (consulté le )
  2. (de) Duncan Campbell, « How NSA access was built into Windows », sur heise online (consulté le )
  • Portail de la cryptologie
  • Portail de la sécurité informatique
Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.