NSAKEY

le _NSAKEY est un nom variable découvert dans le 1999 de Windows NT 4 Service Pack 5 (qui de avait été libéré non décollé de ses données de la mise au point en adressage symbolique ) en août par Andrew D. Fernandes de Cryptonym Corporation . Cette variable a contenu une clef publique de 1024 bits.

Vue d'ensemble

Le logiciels d'exploitation de s de Microsoft les 'exigent toutes les suites de cryptographie qui peuvent entrer dans ses logiciels d'exploitation pour avoir une signature digitale. Quand seulement des suites Microsoft-approuvées de cryptographie peuvent être employées, l'acquiescement aux règlements (OREILLE) d'administration d'exportation de du ministère du commerce des USA , bureau de de l'administration d'exportation (BXA) (maintenant connu sous le nom de bureau d'industrie et sécurité ou BRI) est plus facile. On l'a déjà su que Microsoft emploie deux clefs, un primaire et une pièce de rechange, l'un ou l'autre dont peut créer les signatures valides. La clé primaire est stockée dans le _KEY variable ; Fernandes avait découvert la deuxième clef.

Fernandes a édité sa découverte, touchant outre d'une bourrasque de la spéculation et du développement des nombreuses théories de conspiration de . Si la moitié privée de cette clef étaient possédées réellement par l'agence de sécurité nationale de des Etats-Unis , le NSA (comme suggéré par le nom), elle permettrait à cette agence d'intelligence de renverser la sécurité de tous les utilisateurs de Windows.

En outre, le Windows 2000 a eu une troisième clef avec un but inconnu, a trouvé par Dr. Microsoft réclame ceci est seulement dans de bêtas constructions de Windows 2000 et que son utilisation était pour les prestataires de service cryptographiques de signature qu'elle n'a eu aucun but clair selon van Someren, et elle est peu claire si elle soit présente dans des constructions finales ou juste de bêtas constructions. (Il n'y a aucune « porte arrière » dans des conflits de Windows avec Microsoft, le NSA, et vous et comment l'accès de NSA a été établi dans Windows)

La réaction de Microsoft

Microsoft, cependant, a nié toutes telles suggestions. " ; Ce rapport est imprécis et non fondé. La clef en question est une clef de Microsoft. Elle est maintenue et sauvegardée par Microsoft, et nous n'avons partagé cette clef avec le NSA ou aucun autre party." ; Le symbole de la clef était " ; _NSAKEY" ; parce que le NSA est l'autorité technique de revue pour des contrôles des exportations des États-Unis, et la clef assure la conformité aux lois d'exportation des États-Unis.

Cependant, certaines des actions de Microsoft pendant la discussion ont aggravé la paranoïa publique plutôt que réduit lui.

La conférence d'ordinateurs, de liberté et d'intimité 2000 de (CFP2000) a été tenue de 4 - le du 7 avril 2000 dans le Toronto , Canada . Pendant une présentation à cette conférence, le Duncan Campbell , chargé de recherches aîné au centre d'information électronique d'intimité de (ÉPIQUE), a mentionné la polémique de _NSAKEY comme exemple d'une issue en suspens liée à la sécurité et à la surveillance.

Richard Purcell, directeur de Microsoft de l'intimité de corporation, Campbell approché après sa présentation et exprimé un souhait pour éclaircir la confusion et les doutes au sujet du _NSAKEY. Juste après la conférence, Scott Culp, du centre de réponse de sécurité de Microsoft, Campbell entré en contact et offert de répondre à ses questions. Leur correspondance a commencé cordialement mais est bientôt devenue strained ; Campbell a apparemment jugé que Culp était évasif et Culp a apparemment estimé que Campbell répétait hostilement les questions aux lesquelles il avait déjà répondues. Sur le le 2000 du 28 avril , Culp a déclaré ce " ; nous avons certainement atteint la fin de cette discussion… se développe en spirales rapidement dans le royaume du theory" de conspiration ; et enquêtes de Campbell d'autres ont disparu sans réponse.

Explications d'autres sources

Après beaucoup de discussion comportant des niveaux d'une manière extravagante de variation d'expertise cryptographique, de diverses conclusions ont été présentées. Pour commencer par, quelques observateurs, y compris Fernandes, doute l'OREILLE du BXA ont des conditions spécifiques pour des clefs de secours. Cependant, aucun des commentateurs ne réclame l'expertise légale nécessaire pour discuter avec autorité ce document.

Microsoft insiste sur le fait que la deuxième clef est présent comme support à garder contre la possibilité de perdre la clef secrète primaire. Fernandes et Bruce Schneier que tous les deux doutent de cette explication, précisant que la manière courante de garder contre la perte d'une clef secrète est secret de dédoublant , qui diviserait la clef en plusieurs différentes pièces, que seraient alors distribués dans toute la haute direction. Un tel plan serait bien plus robuste que simplement using deux clefs ; si la deuxième clef est également perdue, Microsoft devrait raccorder ou améliorer chaque copie de Windows dans le monde, comme chaque module cryptographique qu'il a jamais signé.

D'une part, si Microsoft pour penser aux conséquences de la perte principale et créé une première clef sans employer le secret de dédoublant (et a fait ainsi dans pour fixer le matériel qui ne permet pas à la protection d'être affaiblie après la génération de clé), et le NSA précisaient le problème en tant qu'élément du processus de revue, il pourrait expliquer pourquoi Microsoft a affaibli leur arrangement avec une deuxième clef et pourquoi le neuf s'est appelé le _NSAKEY. (La deuxième clef pourrait être soutenue using le de division secret, ainsi perdant les deux clefs n'ont pas besoin d'être un problème.)

Une autre ligne de la spéculation conclut ce Microsoft a inclus une deuxième clef pour pouvoir signer les modules cryptographiques en dehors des Etats-Unis, tout en se conformant toujours à l'OREILLE du BXA. Si des modules cryptographiques devaient être signés dans des endroits multiples, using des clefs multiples est une approche raisonnable. Cependant, aucun module cryptographique ne s'est jamais avéré pour être signé par le _NSAKEY et Microsoft nie que n'importe quelle autre autorité de certification existe.

Une troisième possibilité est que le _NSAKEY permet au NSA ou à d'autres agences de signer leurs propres modules cryptographiques sans être exigé pour révéler ces modules à Microsoft, qui leur permettrait de créer les modules intérieurement qui mettent en application des algorithmes classifiés. Naturellement ces possibilités permettraient également à une agence de signer les modules qui pourraient être utilisés pour miner la sécurité de n'importe quelle installation de Windows. Une telle spéculation est habituellement suivie des commentaires cyniques sur un tel minage de ne pas être difficile même sans accès à l'api cryptographique.

Microsoft nie que le NSA a accès à la clef de secret de _NSAKEY.

La clef est encore présente dans toutes les versions de Windows, bien qu'elle ait été " retitré ; _KEY2." ;

Il est possible d'enlever la seconde, _NSAKEY using ce qui suit : le

There est de bonnes nouvelles parmi le mauvais, cependant. Il s'avère qu'il y a une paille de la manière le " ; crypto_verify" ; la fonction est mise en application. En raison de la manière la crypto vérification se produit, les utilisateurs peuvent facilement éliminer ou remplacer la clef de NSA du du système d'exploitation sans modifier quels de l'original de Microsoft composants. Puisque la clef de NSA est facilement remplacée, il signifie que les non-USA les compagnies sont libres pour installer le " ; strong" ; cryptos services dans Windows, en dehors Microsoft ou l'approbation du NSA. Ainsi le NSA a effectivement enlevé l'exportation commande de " ; strong" ; crypto de Windows. Un programme de démonstration qui remplace la clef de NSA peut être trouvée sur le site Web de Cryptonym.

Clefs publiques de signature de CAPI comme clefs de PGP

En septembre le 1999 , un chercheur anonyme renversé-a machiné les deux clé primaire et le _NSAKEY dans le format PGP-compatible et édité leur aux serveurs de clef de

Clef primaire de signature du CAPI de Microsoft (variable de _KEY)

 Dactylographier le peu/l'identification de l'utilisateur date de KeyID CAPI  principal du pub 1024/346B5095 1999/09/06 Microsoft -----COMMENCER LE BLOC PRINCIPAL PUBLIC DE PGP----- Version : 2.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 -----BLOC PRINCIPAL PUBLIC DE PGP D'EXTRÉMITÉ-----

Clef secondaire de signature du CAPI de Microsoft (variable de _NSAKEY, maintenant _KEY2)

Dactylographier le peu/l'identification de l'utilisateur date de KeyID Microsoft CAPI principal du NSA du pub 1024/51682D1F 1999/09/06 -----COMMENCER LE BLOC PRINCIPAL PUBLIC DE PGP----- Version : 2.3i mQCPAzfTdH0AAAEEALqOFf7jzRYPtHz5PitNhCYVryPwZZJk2B7cNaJ9OqRQiQoi e1YdpAH/OQh3HSQ/butPnjUZdukPB/0izQmczXHoW5f1Q5rbFy0y1xy2bCbFsYij 4ReQ7QHrMb8nvGZ7OW/YKDCX2LOGnMdRGjSW6CmjK7rW0veqfoypgF1RaC0fABEB AAG0LU5TQSdzIE1pY3Jvc29mdCBDQVBJIGtleSA8cG9zdG1hc3RlckBuc2EuZ292 PokBFQMFEDfTdJE+e8qoKLJFUQEBHnsH/ihUe7oq6DhU1dJjvXWcYw6p1iW+0euR YfZjwpzPotQ8m5rC7FrJDUbgqQjoFDr++zN9kD9bjNPVUx/ZjCvSFTNu/5X1qn1r 6h du matin h4Bs6KE5MPpjKRxRkqQjbW4f0cgXg6+LV+V9cNMylZHRef3PZCQa d'it7IHU/ 5DOI5crQ0IWyjQCt9br07BL9C3X5WHNNRsRIr9WiVfPK8eyxhNYl/NiH2GzXYbNe UWjaS2KuJNVvozjxGymcnNTwJltZK4RLZxo05FW2InJbtEfMc+m823vVltm9l/f+ n2iYBAaDs6I/0v2AcVKNy19Cjncc3wQZkaiIYqfPZL19kT8vDNGi9uE= =PhHT -----BLOC PRINCIPAL PUBLIC DE PGP D'EXTRÉMITÉ-----

Voir également

Le a fait confiance à des critères de l'évaluation de système informatique

Random links: