_NSAKEY - _NSAKEY

_NSAKEY was een variabelenaam die in 1999 werd ontdekt in Windows NT 4 SP5 door Andrew D. Fernandes van Cryptonym Corporation. De variabele bevatte een 1024-bits openbare sleutel; dergelijke sleutels worden gebruikt in cryptografie met openbare sleutels voor codering en authenticatie . Vanwege de naam werd echter gespeculeerd dat de sleutel de National Security Agency (NSA) van de Verenigde Staten in staat zou stellen de beveiliging van elke Windows-gebruiker te ondermijnen. Microsoft ontkende de speculatie en zei dat de naam van de sleutel afkomstig was van het feit dat de NSA de technische beoordelingsautoriteit was voor Amerikaanse exportcontroles voor cryptografie .

Overzicht

Microsoft vereist dat alle cryptografiesuites die samenwerken met Microsoft Windows een digitale handtekening hebben . Aangezien alleen door Microsoft goedgekeurde cryptografiesuites met Windows kunnen worden geleverd, is het mogelijk om exportkopieën van dit besturingssysteem te bewaren in overeenstemming met de Export Administration Regulations (EAR), die worden afgedwongen door het Bureau of Industry and Security (BIS).

Het was al bekend dat Microsoft twee sleutels gebruikte, een primaire en een reservesleutel, die beide geldige handtekeningen kunnen maken. Bij het uitbrengen van Service Pack 5 voor Windows NT 4 had Microsoft verzuimd de foutopsporingssymbolen te verwijderen in ADVAPI32.DLL , een bibliotheek die wordt gebruikt voor geavanceerde Windows-functies zoals register en beveiliging. Andrew Fernandes, hoofdwetenschapper bij Cryptonym, vond de primaire sleutel die was opgeslagen in de variabele _KEY en de tweede sleutel kreeg het label _NSAKEY. Fernandes publiceerde zijn ontdekking, waarbij hij een vlaag van speculatie en complottheorieën aanstipte , waaronder de mogelijkheid dat de tweede sleutel eigendom was van de National Security Agency (de NSA) van de Verenigde Staten en de inlichtingendienst in staat stelde de beveiliging van elke Windows-gebruiker te ondermijnen.

Tijdens een presentatie op de conferentie Computers, Freedom and Privacy 2000 (CFP2000) noemde Duncan Campbell , senior research fellow bij het Electronic Privacy Information Center (EPIC), de _NSAKEY-controverse als een voorbeeld van een openstaande kwestie met betrekking tot beveiliging en bewaking.

Bovendien vond Dr. Nicko van Someren een derde sleutel in Windows 2000, waarvan hij betwijfelde of deze een legitiem doel had, en verklaarde dat "het er meer visachtig uitziet".

Reactie van Microsoft

Microsoft ontkende de achterdeur- speculaties over _NSAKEY en zei: "Deze speculatie is ironisch aangezien Microsoft zich consequent heeft verzet tegen de verschillende belangrijke escrow- voorstellen die door de regering worden voorgesteld." Volgens Microsoft was het symbool van de sleutel "_NSAKEY", omdat de NSA de technische beoordelingsautoriteit was voor Amerikaanse exportcontroles voor cryptografie , en de sleutel zorgde voor naleving van de Amerikaanse exportwetten.

Richard Purcell, Microsoft's Director of Corporate Privacy, benaderde Campbell na zijn presentatie en sprak de wens uit om de verwarring en twijfels over _NSAKEY weg te nemen. Direct na de conferentie nam Scott Culp, van het Microsoft Security Response Center, contact op met Campbell en bood aan zijn vragen te beantwoorden. Hun correspondentie begon hartelijk, maar werd al snel gespannen; Campbell had blijkbaar het gevoel dat Culp ontwijkend was en Culp had blijkbaar het gevoel dat Campbell op vijandige wijze vragen herhaalde die hij al had beantwoord. Op 28 april 2000 verklaarde Culp dat "we zeker het einde van deze discussie hebben bereikt ... [die] snel in het rijk van de samenzweringstheorie terechtkomt".

Microsoft beweerde dat de derde sleutel alleen in bètaversies van Windows 2000 zat en dat het bedoeld was om cryptografische serviceproviders te ondertekenen .

De Mozilla- pagina met veelgestelde vragen over cryptografie vermeldt:

Het is namelijk onder bepaalde omstandigheden mogelijk om via een API een exportvergunning te verkrijgen voor software die cryptografische functies aanroept. De implementatie door Microsoft van de Microsoft Cryptographic API (CryptoAPI)-specificatie is bijvoorbeeld goedgekeurd voor export vanuit de VS, hoewel het een API implementeert waarmee derde partijen, inclusief derde partijen buiten de VS, afzonderlijke modules kunnen toevoegen ("Cryptographic Service Providers" of CSP's) die cryptografische functionaliteit implementeren. Deze exportgoedkeuring is vermoedelijk mogelijk gemaakt omdat a) de CryptoAPI-implementatie vereist dat CSP's van derden digitaal worden ondertekend door Microsoft en pogingen om CSP's die niet zo ondertekend zijn aan te roepen, verwerpt; b) door dit ondertekeningsproces kan Microsoft ervoor zorgen dat de relevante Amerikaanse exportcontroleregels worden nageleefd (ze zouden bijvoorbeeld vermoedelijk geen CSP ondertekenen die buiten de VS is ontwikkeld en die sterke cryptografie implementeert); en c) Microsoft's CryptoAPI-implementatie is alleen beschikbaar in uitvoerbare vorm, en wordt dus verondersteld redelijk bestand te zijn tegen manipulatie door gebruikers om de CSP-controle van digitale handtekeningen uit te schakelen.

Microsoft verklaarde dat de tweede sleutel aanwezig is als back-up om te voorkomen dat de primaire geheime sleutel verloren gaat. Fernandes betwijfelt deze verklaring en wijst erop dat de algemeen aanvaarde manier om te waken tegen verlies van een geheime sleutel geheime splitsing is , waarbij de sleutel in verschillende delen zou worden verdeeld, die vervolgens door het senior management zouden worden verspreid. Hij verklaarde dat dit veel robuuster zou zijn dan het gebruik van twee sleutels; als de tweede sleutel ook verloren gaat, zou Microsoft elk exemplaar van Windows ter wereld moeten patchen of upgraden, evenals elke cryptografische module die het ooit had ondertekend.

Aan de andere kant, als Microsoft niet heeft nagedacht over de gevolgen van sleutelverlies en een eerste sleutel heeft gemaakt zonder geheime splitsing te gebruiken (en dit deed in beveiligde hardware die niet toestaat dat de bescherming wordt verzwakt na het genereren van de sleutel), en de NSA wees dit probleem als onderdeel van het beoordelingsproces heeft opgelost, zou dit kunnen verklaren waarom Microsoft hun schema met een tweede sleutel heeft verzwakt en waarom de nieuwe _NSAKEY heette. (Van de tweede sleutel kan een back-up worden gemaakt met geheime splitsing, dus het verlies van beide sleutels zou geen probleem moeten zijn.) Een andere mogelijkheid is dat Microsoft een tweede sleutel heeft toegevoegd om cryptografische modules buiten de Verenigde Staten te kunnen ondertekenen, terwijl het nog steeds voldoet aan de BIS's OOR. Als cryptografische modules op meerdere locaties moeten worden ondertekend, is het gebruik van meerdere sleutels een redelijke benadering. Er is echter nooit gevonden dat een cryptografische module is ondertekend door _NSAKEY, en Microsoft ontkent dat er een andere certificeringsinstantie bestaat.

Het was mogelijk om de tweede _NSAKEY te verwijderen.

Er is echter goed nieuws onder het slechte. Het blijkt dat er een fout zit in de manier waarop de functie "crypto_verify" is geïmplementeerd. Vanwege de manier waarop de crypto-verificatie plaatsvindt, kunnen gebruikers de NSA-sleutel eenvoudig uit het besturingssysteem verwijderen of vervangen zonder de originele componenten van Microsoft te wijzigen. Aangezien de NSA-sleutel gemakkelijk kan worden vervangen, betekent dit dat niet-Amerikaanse bedrijven vrij zijn om "sterke" cryptodiensten in Windows te installeren, zonder de goedkeuring van Microsoft of de NSA. Zo heeft de NSA de exportcontrole van "sterke" cryptovaluta effectief van Windows verwijderd. Een demonstratieprogramma dat de NSA-sleutel vervangt, is te vinden op de website van Cryptonym.

PGP-sleutels

In september 1999 heeft een anonieme onderzoeker zowel de primaire sleutel als de _NSAKEY reverse-engineered in een PGP- compatibel formaat en deze op sleutelservers gepubliceerd .

Primaire sleutel (_KEY)

 Type Bits/KeyID Date User ID
 pub 1024/346B5095 1999/09/06 Microsoft's CAPI key <[email protected]>

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

Secundaire sleutel (_NSAKEY en _KEY2)

 Type Bits/KeyID Date User ID
 pub 1024/51682D1F 1999/09/06 NSA's Microsoft CAPI key <[email protected]>

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

Zie ook

• Lotus Notes - openlijk een NSA-sleutel gebruikt om te voldoen aan de exportvoorschriften voor cryptografie
• Clipper-chip

Referenties