WinXP activation: what happens under the covers?

WinXP diaries When you use the Windows XP product activation system, Microsoft assures us, it's an entirely anonymous transaction. Your machine sends a key to Redmond, Redmond sends an unlock key back, and your installation is validated forever. Or at least until you've gone one hardware upgrade too far, and you have to call them up and ask for mercy.

It seems to us that this is all true, not because Microsoft is fundamentally a nice company, but because of the hellish damage that would be wreaked if it were discovered that Redmond was doing other stuff on the sly. Microsoft got into trouble enough when it 'accidentally' collected hardware data it didn't use (honest) and later destroyed, and vast swathes of the user community are poised to believe the slightest suggestion that the company is up to no good. Basically it would be incredibly, spectacularly dumb for Microsoft to be anything but dead straight about product activation, and it would be a sure recipe for wrecking WinXP adoption.

But on the other hand... If you think about what .NET involves, it's philosophically, fundamentally opposed to the notion of a single product you buy, you install, and then run forever without it phoning home. XP to some extent has to be a .NET product, and .NET products are services - they keep transacting, updating, phoning home, and you rent them. On the one hand Microsoft has to be whiter than white with XP, on the other it has to prepare for the future, so you could maybe expect tensions.

Some of these might be visible from some network sniffing a source carried out during the XP product activation process. It's not entirely clear to us what was happening, but the process seems to have been rather more complex than just an anonymous exchange of numbers. It seems to us that in the XP beta 2 code maybe there's the capability for a non-anonymous transaction to occur. This may indicate what Microsoft intended to do earlier, or it may suggest what the company plans for future revs.

Anyway, this is what our source reports. When the activation wizard is started, it does a get on http://wpa.one.microsoft.com which returns:

"The page must be viewed over a secure channel
The page you are trying to view requires the use of "https" in the address."

Try it with https and you get:

"This Page is not for Display
If you feel you have reached this page in error, please contact your manager".

Then it requests:

http://download.windowsupdate.com/msdownload/update
/v3/static/trustedr/en/authrootseq.txt

Which produces:

1401C084E6489054CB

then it gets:
http://download.windowsupdate.com/msdownload/update
/v3/static/trustedr/en/authrootstl.cab

This CAB file only contains one file: authroot.stl, a certificate trust list time stamped Monday, January 22, 2001 11:23:08 PM. The certificate status states: "This certificate does not appear to be valid for the selected purpose."

Finally it gets:

http://download.windowsupdate.com/msdownload/update
/v3/static/trustedr/en/xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxx.crt

This would seem to represent a machine certificate issued by Secure Server Certification Authority, RSA Data Security, its purpose being to ensure the identity of a remote computer. That last URL is incidentally the only one we can't verify, presumably because it's specific to the machine that's actually doing the activate.

It would seem possible for the product key, the local machine and this machine certificate to be linked, but Microsoft couldn't possibly be doing that and keeping the transaction anonymous. So it's a puzzle. Our informant adds that he tried the test twice, but the second time the transaction was completely HTTPS, and impossible to fathom. We haven't been able to reproduce it ourselves yet, but we'd be interested to hear from anybody else who tries a bit of sniffing while activating.

The machine certificate itself seems to have some validity. A complete reinstall of WinXP on the same machine, followed by the installation of the certificate, results in an installation that's already activated. Our source also points out that the default for Update Root Certificates in Windows Components is "selected", which suggests there's a capability for installations using compromised keys to be zeroed.

Microsoft itself has described a similar process with reference to compromised certificates in Windows Media Player, so it's not a massive intellectual leap to think of this being applied to Windows itself. Which might be the .NET rental version, but not the current one. Surely? ®