On May 4th,1999, Microsoft released Windows NT 4.0, Service Pack 5.
Hidden away deep inside that operating system, as they had been since NT 4's original release,
were two important cryptographic keys.
Their existence had been speculated upon by researchers and their purpose was believed
to be understood.
But that all changed with Service Pack 5, when Microsoft made an error in producing
the CDs.
In preparing one DLL file to be shipped with the operating system, Microsoft had somehow
skipped or omitted an important step: they had forgotten to remove their private debugging
symbols from the DLL.
That meant that the secret, internal code names of every variable and function were
now contained within the DLL for all the world to see.
And what the world saw sent shockwaves through the computing world.
A research scientist named Andrew Fernandes analyzed the symbols and soon discovered the
names of those two cryptographic secrets.
The first seemed innocuous enough - it was simply named the "KEY".
But the second was more onerous.
It was named the "NSA KEY".
Why had Microsoft apparently included a key from the NSA in Windows, and what was its
purpose?
Had they been forced or coerced by the government to include a breaking key that could reveal
everyone's private data?
Was it a cryptographic back door?
The Internet is a fervent breeding ground for conspiracy theories, and many quickly
erupted surrounding the key.
The consensus quickly emerged that the key must indeed be a back door encryption key
of some sort: clearly the NSA has cajoled, convinced, threatened, or perhaps even forced
Microsoft to include it.
And with it, so the theories went, Microsoft and the NSA could decrypt all of your private,
encrypted data and correspondence without having to break the encryption.
The could even intercept SSL.
After all, there was no need to break into what they already had the key for.
What's the truth, and who would know?
Well, you could start by asking someone who actually worked on NT4.
Someone like myself, for example.
I'd been a developer on every Microsoft operating system since MS-DOS and Windows NT4 was no
exception.
In fact, I've got a soft spot for NT 4, and it's probably my favorite version of Windows
to have worked on.
NT4 was really about the fusion between the powerful NT kernel and the popular Windows
95 user interface; it had been my team's job to make that fusion happen, grafting and tweaking
and fixing the code from the Windows 95 desktop and shell in order to adapt it to Windows
NT.
Converting the code to Windows NT was not as straightforward as you might imagine.
For one, the APIs were similar between Win9X and WinNT, but they were rarely the same.
In many cases an API like DirectX or OpenGL would exist on one but be entirely missing
from the other.
And like most software of its time, Windows 95 used 8-bit ASCII strings to represent text
internally, whereas Windows NT used 16-bit Unicode to do so.
Windows 95 also assumed that you had a 486 or Pentium CPU from Intel, but Windows NT
had to run on Alpha, MIPS, and the PowerPC computers.
Putting the Windows 95 UI on Windows NT was a bit of a rogue experiment, because NT was
supposed to be getting a new, better, flashier and more powerful user interface from the
Cairo project, Microsoft's future-leaning successor to NT itself.
Many of us, however, could not or did not want to wait that long.
The project grew up under the secret codeword of Tukwila, a town near Seattle.
The slogan was "We can get there from here!".
When they found out about it, management pushed back hard on the Tukwila branding and codework,
and it soon became the Shell Update Release, or SUR.
The new codename?
It was just "SUR: We don't need no stinking codename'.
Porting the Win95 UI grew up as something of a skunkworks project in a few offices and
then spread like wildfire once the idea caught on.
A few feelings were hurt and a hole or two got punched in the hallway wall, but the Cairo
guys got over it eventually.
The amount of work required to bring the entire Windows 95 user interface to NT was significant,
and our team worked around the clock at times to make it happen.
In the end, despite a very late start, Windows NT 4 shipped exactly one year to the day after
Windows 95, and looked exactly like it.
Microsoft was running magazine ads for NT in those days that said it best.
It showed a giant humpback whale cruising with the caption "Massive Power, just below
the surface".
It was clever, in that it conveyed there was a lot going on under the covers with Windows
NT, even if it did subconsciously suggest that NT was as big as a whale at the same
time.
When the revelations surrounding the NSAKey came to light in the press, I was as stunned
and incredulous as the next person.
I was certain that there was no way we had shipped a backdoor key in the operating system.
But I had to know, to see for myself.
And so, I checked with the ultimate authority: the code itself.
I unlocked my workstation and navigated down to the appropriate spot in the code.
It wasn't something I was in the habit of looking at, but once you know what you're
looking for, everything is just a grep away, so it didn't take long to find it.
And sure enough, the key was labelled as the NSAKey.
But what was it?
And why was it in there?
To answer those questions we have to go back to the late 80s and early 90s.
That's back when crypto was a weapon, and that's a literal statement.
Anything with stronger than 40-bit encryption was classified as a munition.
The reasons why aren't especially important to our discussion, but as you can imagine
during the Cold War the United States was eager to prevent technology from entering
Soviet hands.
Powerful crypto was one of those things, and so you simply were not allowed to export it.
This in turn meant you could and often did find two versions of software: one with weaker
40-bit encryption for the export market and then a 128 or perhaps even a 256-bit version
for the domestic market.
Windows had enough variants at the time, and the last thing Microsoft would want to do
was double that number by splitting every SKU into high and low power crypto versions.
It would be much simpler to make the crypto engines into DLLs that could be loaded by
the operating system once it was up and running.
That way one unified version of Windows could work with either the domestic or export versions.
And that was half of the problem - what if someone were to simply copy the DLL from the
domestic version onto the export version?
And the other half of the problem was preventing people from using their own high-power encryption
plugins on an export-controlled system.
Microsoft was required by law to enforce, as best it could, the rules of which crypto
providers could be loaded on what system through the use of digital signatures.
Imagine each crypto provider was signed with a unique private key.
You include the public key somewhere inside Windows and when someone attempts to load
a crypto provider, you check its signature with the public key.
If it matches, then the provider must have been signed by the entity holding the private
key.
And that entity was Microsoft in the first place.
The first KEY, simply called "The KEY", is that key.
It is the public key used to verify the cryptographic identity of a pluggable crypto provider, in
accordance with the Export Administration Regulations, or E-A-Rs, which are enforced
by the Bureau of Industry and Security.
The techncial review authority for US Cryptographic Export controls is none other than the National
Security Agency, or NSA.
The NSAKey was used to ensure compliance with those US Export controls, and hence the name.
But why were there two keys, you might reasonably ask?
Imagine that there was only one key.
And imagine that when you generated it, you used a cipher box or something similar, and
then you baked the public key into Windows crypto.
What happens if the original private key were lost?
Then no one would be able to produce a crypto provider for Windows, not even Microsoft itself.
And so, they added a backup key just in case.
As I understand it, in the event the original key is lost the system can dynamically switch
over to the secondary key.
My guess, and it's educated guess but just a guess nonetheless, is that the first key
was generated in a monolithic fashion where it couldn't later be split up.
In order to guard against loss, today you would normally split the key up into manageable
portions and distribute those portions to your executives.
No single executive or even subgroup of executives can make any use of the key fragments, but
if the entire key needs to be reconstructed, as long as everyone agrees, you can do so
because they have all the pieces.
The problem is that your key has to be generated in a way that's amenable to key splitting,
and my hunch is that the first key was not created that way.
My other hunch is that the second key WAS generated that way, which is why they won't
need a third key if the first one is lost.
Remember the old adage, two is one and one is none.
You need a backup.
So that's the non-conspiracy version.
The conspiracy version is way more exciting, it's just not very plausible.
But let's play it through for a moment to see where it goes.
Let's assume that the NSA somehow coerced or forced to Microsoft to include that key.
First, what would the NSA key actually be used for?
If you've got a backdoor key, then presumably you want to use that key to get into something.
But what exactly are you trying to get into?
The answer in this case is: not much.
Yes, there are some persistent store formats in Windows NT 4 where the encryption keys
were encrypted with the NSAKey and stored on disk.
One example is the private keys for IIS SSL certificates; another is the protected storage
system that stores things like your credit card numbers in the very earliest versions
of Internet Explorer.
That only last through about IE 3, however, as far as I know.
But guess what - those keys aren't very useful without also having access to either the corresponding
public key, or the private key for the user's machine.
And those keys aren't encrypted with the NSAKey, they are stored in a CryptoAPI provider of
some sort that is not encrypted at all.
So even if you had access to the disk and could get to those keys, you still wouldn't
be able to do anything useful with them without also having possession of either:
-The corresponding public key (eg.
IIS server certificate), or -The user's private cryptographic key pair
from their own personal computer.
And neither of those things are encrypted, they're kept on disk in plaintext.
The onus is on the user to protect and hide them.
Hecne, there is no backdoor into Windows encryption whatsoever.
As noted, you could get the keys, but they wouldn't do you any good without also having
access to either The corresponding public key or the user's private cryptographic key
pair.
Of course there will be those who disagree and still pound the table claiming this key
is or was a backdoor to user data.
If it was, riddle me this: the key's been known for almost 20 years.
Heck, I'll even post it in the video description to make it easy for you.
If there were any use or utility to that key, it would have been exploited by others by
now.
Heck, it would have been exploited within about 3 days of being found, I imagine.
But what about newer versions of Windows?
After all, this was back when 40-bit encryption was still considered strong enough for export
use and before anyone had really thought through all of these issues.
Surely Microsoft has fixed this by now!
Well yes... and no.
The NSAKey is still present in every version of Windows from NT4 Service Pack 5 on up,
but it is no longer used for crypto provider signatures.
That's because the NSA changed their rules in 1996 and allowed strong crypto to be exported
without restriction.
And thus, from then on forward there was no need to use digital signatures any more - you
could simply ship all of the providers unencrypted and signed with a common key.
So, what exactly is that NSAKey still being used for?
The answer may surprise you: as far as I can tell, nothing at all!
That's right; it isn't used for anything in Windows today.
It just sits there, doing nothing useful whatsoever.
I don't know why they haven't removed it yet.
I suppose there could be a compatibility case I haven't thought of.
Perhaps someone just forgot, but either I'm told that every version of Windows from NT4
Service Pack 5 on up still contains a key that isn't used for anything.
And that's the only suspicious part - if the key is of no use, why keep it in the code?
On the other hand, the very fact that there are multiple keys at all is reassuring.
Even if the NSAKey originated with the NSA, and it very well might have even for the legitimate
crypto purposes, that means the key is derived from the NSA's keychain, not Microsoft's.
I think that alone is fairly good proof that Microsoft was not willing to allow the NSA
access to its own secret key.
I hope this helps to clear up any confusion about the NSAKEY and what it was actually
used for in Windows NT 4 Service Pack 5, as well as dispel any conspiracy theories you
might have heard about it.
If you want to look at the code yourself, it's there waiting for you - just use your
favorite search engine with "NSAKey" as the query!"
Of course, if you disagree, let me know in the comments, but any b big claims should
include links to big evidence!
If along the way you found today's episode to be any combination of entertaining or informative,
I'd be honored if you'd consider leaving it a like and subscribing to my channel.
If you have any interest in matters related to Autism, Asperger's, or ASD, please check
out my book on Amazon, Secrets of the Autistic Millionaire.
It's got nothing to do with money and everything to do with living a successful life on the
spectrum.
It's everything I know now that I wish I'd known back then.
Remember I'm mostly in this for the subs and likes, so please be sure to leave me one of
each before you go today.
In the meantime, and in between time, I hope to see you next time, right here in Dave's
Garage.