[Reader-list] The details of XP (Windows)
Jaswinder Singh Kohli
jskohli at fig.org
Fri Jul 13 01:32:27 IST 2001
Hi
somewhere on the NET I found this paper.
This details the aactivation of Xp and what
information it transmits and etc......
BTW I must say this is the Koolest one
man see how every Hardware you have is hidden
inside your ProductID.
like Network Card MAC Addrees, CDROM, HDD, Graphics Adapter
CPU Serial NO(remember Intel PIII serial no support)
IDE Controller, processor model,RAM size
something from every thing, imean , serial no,
Brandname, model no. etc... goes into the key
of Win XP.
See how much time spent on this thing,
May be they have spent same time on making Windows itself
--
Regards
Jaswinder Singh Kohli
jskohli at fig.org
::::::::::::::::::::::::::::::::::::::::::::::::
The Uni(multi)verse is a figment of its own imagination.
In truth time is but an illusion of 3D frequency grid programs.
-------------- next part --------------
Inside Windows Product Activation
A Fully Licensed Paper
July 2001
Fully Licensed GmbH, Rudower Chaussee 29, 12489 Berlin, Germany
http://www.licenturion.com
>> INTRODUCTION
The current public discussion of Windows Product Activation (WPA) is
characterized by uncertainty and speculation. In this paper we supply
the technical details of WPA - as implemented in Windows XP - that
Microsoft should have published long ago.
While we strongly believe that every software vendor has the right to
enforce the licensing terms governing the use of a piece of licensed
software by technical means, we also do believe that each individual
has the right to detailed knowledge about the full implications of the
employed means and possible limitations imposed by it on software
usage.
In this paper we answer what we think are currently the two most
important open questions related to Windows Product Activation.
* Exactly what information is transmitted during activation?
* How do hardware modifications affect an already activated
installation of Windows XP?
Our answers to these questions are based on Windows XP Release
Candidate 1 (build 2505). Later builds as well as the final version of
Windows XP might differ from build 2505, e.g. in the employed
cryptographic keys or the layout of some of the data
structures.
However, beyond such minor modifications we expect Microsoft to cling
to the general architecture of their activation mechanism. Thus, we
are convinced that the answers provided by this paper will still be
useful when the final version of Windows XP ships.
This paper supplies in-depth technical information about the inner
workings of WPA. Still, the discussion is a little vague at some
points in order not to facilitate the task of an attacker attempting
to circumvent the license enforcement supplied by the activation
mechanism.
XPDec, a command line utility suitable for verifying the presented
information, can be obtained from http://www.licenturion.com/xp/. It
implements the algorithms presented in this paper. Reading its source
code, which is available from the same location, is highly
recommended.
We have removed an important cryptographic key from the XPDec source
code. Recompiling the source code will thus fail to produce a working
executable. The XPDec executable on our website, however, contains
this key and is fully functional.
So, download the source code to learn about the inner workings of WPA,
but obtain the executable to experiment with your installation of
Windows XP.
We expect the reader to be familiar with the general procedure of
Windows Product Activation.
>> INSIDE THE INSTALLATION ID
We focused our research on product activation via telephone. We did
so, because we expected this variant of activation to be the most
straight-forward to analyze.
The first step in activating Windows XP via telephone is supplying the
call-center agent with the Installation ID displayed by msoobe.exe,
the application that guides a user through the activation process. The
Installation ID is a number consisting of 50 decimal digits that are
divided into groups of six digits each, as in
002666-077894-484890-114573-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XX
In this authentic Installation ID we have substituted digits that we
prefer not to disclose by 'X' characters.
If msoobe.exe is invoked more than once, it provides a different
Installation ID each time.
In return, the call-center agent provides a Confirmation ID matching
the given Installation ID. Entering the Confirmation ID completes the
activation process.
Since the Installation ID is the only piece of information revealed
during activation, the above question concerning the information
transmitted during the activation process is equivalent to the
question
'How is the Installation ID generated?'
To find an answer to this question, we trace back each digit of the
Installation ID to its origins.
>>> Check digits
The rightmost digit in each of the groups is a check digit to guard
against simple errors such as the call center agent's mistyping of one
of the digits read to him or her. The value of the check digit is
calculated by adding the other five digits in the group, adding the
digits at even positions a second time, and dividing the sum by
seven. The remainder of the division is the value of the check
digit. In the above example the check digit for the first group (6) is
calculated as follows.
1 | 2 | 3 | 4 | 5 <- position
---+---+---+---+---
0 | 0 | 2 | 6 | 6 <- digits
0 + 0 + 2 + 6 + 6 = 14 (step 1: add all digits)
0 + 6 + 14 = 20 (step 2: add even digits again)
step 3: division
20 / 7 = 2, remainder is 20 - (2 * 7) = 6
=> check digit is 6
Adding the even digits twice is probably intended to guard against the
relatively frequent error of accidentally swapping two digits while
typing, as in 00626 vs. 00266, which yield different check digits.
>>> Decoding
Removing the check digits results in a 41-digit decimal number. A
decimal number of this length roughly corresponds to a 136-bit binary
number. In fact, the 41-digit number is just the decimal encoding of
such a 136-bit multi-precision integer, which is stored in little
endian byte order as a byte array. Hence, the above Installation ID
can also be represented as a sequence of 17 bytes as in
0xXX 0xXX 0xXX 0xXX 0xXX 0xXX 0xXX 0xXX
0x94 0xAA 0x46 0xD6 0x0F 0xBD 0x2C 0xC8
0x00
In this representation of the above Installation ID 'X' characters
again substitute the digits that we prefer not to disclose. The '0x'
prefix denotes hex notation throughout this paper.
>>> Decryption
When decoding arbitrary Installation IDs it can be noticed that the
most significant byte always seems to be 0x00 or 0x01, whereas the
other bytes look random. The reason for this is that the lower 16
bytes of the Installation ID are encrypted, whereas the most
significant byte is kept in plaintext.
The cryptographic algorithm employed to encrypt the Installation ID is
a proprietary four-round Feistel cipher. Since the block of input
bytes passed to a Feistel cipher is divided into two blocks of equal
size, this class of ciphers is typically applied to input blocks
consisting of an even number of bytes - in this case the lower 16 of
the 17 input bytes. The round function of the cipher is the SHA-1
message digest algorithm keyed with a four-byte sequence.
Let + denote the concatenation of two byte sequences, ^ the XOR
operation, L and R the left and right eight-byte input half for one
round, L' and R' the output halves of said round, and First-8() a
function that returns the first eight bytes of an SHA-1 message
digest. Then one round of decryption looks as follows.
L' = R ^ First-8(SHA-1(L + Key))
R' = L
The result of the decryption is 16 bytes of plaintext, which are -
together with the 17th unencrypted byte - from now on interpreted as
four double words in little endian byte order followed by a single
byte as in
name | size | offset
-----+-------------+-------
H1 | double word | 0
H2 | double word | 4
P1 | double word | 8
P2 | double word | 12
P3 | byte | 16
H1 and H2 specify the hardware configuration that the Installation ID
is linked to. P1 and P2 as well as the remaining byte P3 contain the
Product ID associated with the Installation ID.
>>> Product ID
The Product ID consists of five groups of decimal digits, as in
AAAAA-BBB-CCCCCCC-DDEEE
If you search your registry for a value named 'ProductID', you will
discover the ID that applies to your installation. The 'About' window
of Internet Explorer should also yield your Product ID.
>>>> Decoding
The mapping between the Product ID in decimal representation and its
binary encoding in the double words P1 and P2 and the byte P3 is
summarized in the following table.
digits | length | encoding
--------+---------+---------------------------------------
AAAAA | 17 bits | bit 0 to bit 16 of P1
BBB | 10 bits | bit 17 to bit 26 of P1
CCCCCCC | 28 bits | bit 27 to bit 31 of P1 (lower 5 bits)
| | bit 0 to bit 22 of P2 (upper 23 bits)
DDEEE | 17 bits | bit 23 to bit 31 of P2 (lower 9 bits)
| | bit 0 to bit 7 of P3 (upper 8 bits)
The meaning of each of the five groups of digits is documented in the
next table.
digits | meaning
--------+-------------------------------------------------
AAAAA | apparently always 55034 (in Windows XP RC1)
BBB | most significant three digits of Raw Product Key
| (see below)
CCCCCCC | least significant six digits of Raw Product Key
| plus check digit (see below)
DD | index of the public key used to verify the
| Product Key (see below)
EEE | random value
As can be seen, the (Raw) Product Key plays an important role in
generating the Product ID.
>>>> Product Key
The Raw Product Key is buried inside the Product Key that is printed
on the sticker distributed with each Windows XP CD. It consists of
five alphanumeric strings separated by '-' characters, where each
string is composed of five characters, as in
FFFFF-GGGGG-HHHHH-JJJJJ-KKKKK
Each character is one of the following 24 letters and digits:
B C D F G H J K M P Q R T V W X Y 2 3 4 6 7 8 9
Very similar to the decimal encoding of the Installation ID the 25
characters of the Product Key form a base-24 encoding of the binary
representation of the Product Key. Decoding the Product Key yields a
multi-precision integer of roughly 115 bits, which is stored - again
in little endian byte order - in an array of 15 bytes. Decoding the
above Product Key results in the following byte sequence.
0x6F 0xFA 0x95 0x45 0xFC 0x75 0xB5 0x52
0xBB 0xEF 0xB1 0x17 0xDA 0xCD 0x00
Of these 15 bytes the least significant four bytes contain the Raw
Product Key in little endian byte order. The least significant bit is
removed by shifting this 32-bit value (0x4595FA6F - remember the
little endian byte order) to the left by one bit position, resulting
in a Raw Product Key of 0x22CAFD37, or
583728439
in decimal notation.
The eleven remaining bytes form a digital signature, allowing
verification of the authenticity of the Product Key by means of a
hard-coded public key.
>>>> Product Key -> Product ID
The three most significant digits, i.e. 583, of the Raw Product Key's
nine-digit decimal representation directly map to the BBB component of
the Product ID described above.
To obtain the CCCCCCC component, a check digit is appended to the
remaining six digits 728439. The check digit is chosen such that the
sum of all digits - including the check digit - is divisible by
seven. In the given case, the sum of the six digits is
7 + 2 + 8 + 4 + 3 + 9 = 33
which results in a check digit of 2, since
7 + 2 + 8 + 4 + 3 + 9 + 2 = 33 + 2 = 35
which is divisible by seven. The CCCCCCC component of the Product ID
is therefore 7284392.
For verifying a Product Key, more than one public key is available. If
verification with the first public key fails, the second is tried,
etc. The DD component of the Product ID specifies which of the public
keys in this sequence was successfully used to verify the Product Key.
This mechanism might be intended to support several different parties
generating valid Product Keys with different individual private keys.
However, the different private keys might also represent different
versions of a product. A Product Key for the 'professional' release
could then be signed with a different key than a Product Key for the
'server' release. The DD component would then represent the product
version.
Finally, a valid Product ID derived from our example Product Key might
be
55034-583-7284392-00123
which indicates that the first public key (DD = index = 0) matched and
123 was chosen as the random number EEE.
The randomly selected EEE component is the reason for msoobe.exe
presenting a different Installation ID at each invocation. Because of
the applied encryption this small change results in a completely
different Installation ID.
So, the Product ID transmitted during activation will most probably
differ in the last three digits from your Product ID as displayed by
Internet Explorer or as stored in the registry.
>>> Hardware Information
As discussed above, the hardware configuration linked to the
Installation ID is represented by the two double words H1 and H2.
>>>> Bit-fields
For this purpose, the double words are divided into twelve
bit-fields. The relationship between the computer hardware and the
bit-fields is given in the following table.
double word | offset | length | bit-field value based on
------------+--------+--------+----------------------------
H1 | 0 | 10 | volume serial number string
| | | of system volume
H1 | 10 | 10 | network adapter MAC address
| | | string
H1 | 20 | 7 | CD-ROM drive hardware
| | | identification string
H1 | 27 | 5 | graphics adapter hardware
| | | identification string
H2 | 0 | 3 | unused, set to 001
H2 | 3 | 6 | CPU serial number string
H2 | 9 | 7 | harddrive hardware
| | | identification string
H2 | 16 | 5 | SCSI host adapter hardware
| | | identification string
H2 | 21 | 4 | IDE controller hardware
| | | identification string
H2 | 25 | 3 | processor model string
H2 | 28 | 3 | RAM size
H2 | 31 | 1 | 1 = dockable
| | | 0 = not dockable
Bit 31 of H2 specifies, whether the bit-fields represent a notebook
computer that supports a docking station. If docking is possible, the
activation mechanism will be more tolerant with respect to future
hardware modifications. Here, the idea is that plugging a notebook
into its docking station possibly results in changes to its hardware
configuration, e.g. a SCSI host adapter built into the docking station
may become available.
Bits 2 through 0 of H2 are unused and always set to 001.
If the hardware component corresponding to one of the remaining ten
bit-fields is present, the respective bit-field contains a non-zero
value describing the component. A value of zero marks the hardware
component as not present.
All hardware components are identified by a hardware identification
string obtained from the registry. Hashing this string provides the
value for the corresponding bit-field.
>>>> Hashing
The hash result is obtained by feeding the hardware identification
string into the MD5 message digest algorithm and picking the number of
bits required for a bit-field from predetermined locations in the
resulting message digest. Different predetermined locations are used
for different bit-fields. In addition, a hash result of zero is
avoided by calculating
Hash = (Hash % BitFieldMax) + 1
where BitFieldMax is the maximal value that may be stored in the
bit-field in question, e.g. 1023 for a 10-bit bit-field, and 'x % y'
denotes the remainder of the division of x by y. This results in
values between 1 and BitFieldMax. The obtained value is then stored in
the respective bit-field.
>>>> RAM bit-field
The bit-field related to the amount of RAM available to the operating
system is calculated differently. The seven valid values specify the
approximate amount of available RAM as documented in the following
table.
value | amount of RAM available
------+---------------------------
0 | (bit-field unused)
1 | below 32 MB
2 | between 32 MB and 63 MB
3 | between 64 MB and 127 MB
4 | between 128 MB and 255 MB
5 | between 256 MB and 511 MB
6 | between 512 MB and 1023 MB
7 | above 1023 MB
It is important to note that the amount of RAM is retrieved by calling
the GlobalMemoryStatus() function, which reports a few hundred
kilobytes less than the amount of RAM physically installed. So, 128 MB
of RAM would typically be classified as "between 64 MB and 127 MB".
>>>> Real-world example
Let us have a look at a real-world example. On one of our test systems
the hardware information consists of the following eight bytes.
0xC5 0x95 0x12 0xAC 0x01 0x6E 0x2C 0x32
Converting the bytes into H1 and H2, we obtain
H1 = 0xAC1295C5 and H2 = 0x322C6E01
Splitting H1 and H2 yields the next table in which we give the value
of each of the bit-fields and the information from which each value is
derived.
dw & | |
offset | value | derived from
-------+-------+-----------------------------------------------
H1 0 | 0x1C5 | '1234-ABCD'
H1 10 | 0x0A5 | '00C0DF089E44'
H1 20 | 0x37 | 'SCSI\CDROMPLEXTOR_CD-ROM_PX-32TS__1.01'
H1 27 | 0x15 | 'PCI\VEN_102B&DEV_0519&SUBSYS_00000000&REV_01'
H2 0 | 0x1 | (unused, always 0x1)
H2 3 | 0x00 | (CPU serial number not present)
H2 9 | 0x37 | 'SCSI\DISKIBM_____DCAS-34330______S65A'
H2 16 | 0x0C | 'PCI\VEN_9004&DEV_7178&SUBSYS_00000000&REV_03'
H2 21 | 0x1 | 'PCI\VEN_8086&DEV_7111&SUBSYS_00000000&REV_01'
H2 25 | 0x1 | 'GenuineIntel Family 6 Model 3'
H2 28 | 0x3 | (system has 128 MB of RAM)
H2 31 | 0x0 | (system is not dockable)
>>> Using XPDec
XPDec is a utility to be run from the command prompt. It may be
invoked with one of four command line options to carry out one of four
tasks.
>>>> XPDec -i
This option enables you to access the information hidden in an
Installation ID. It decodes the Installation ID, decrypts it, and
displays the values of the hardware bit-fields as well as the Product
ID of your product. Keep in mind that the last three digits of the
Product ID contained in the Installation ID are randomly selected and
differ from the Product ID displayed by Internet Explorer.
The only argument needed for the '-i' option is the Installation ID,
as in
XPDec -i 002666-077894-484890-114573-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XX
>>>> XPDec -p
To help you trace the origin of your Product ID, this option decodes a
Product Key and displays the Raw Product Key as it would be used in a
Product ID.
The only argument needed for the '-p' option is the Product Key, as in
XPDec -p FFFFF-GGGGG-HHHHH-JJJJJ-KKKKK
Note that this option does not verify the digital signature of the
Product Key.
>>>> XPDec -v
This option calculates the hash of a given volume serial number. It
was implemented to illustrate our description of string hashing. First
use '-i' to display the hardware bit-fields. Then use this option to
verify our claims concerning the volume serial number hash.
The only argument needed for the '-v' option is the volume serial
number of your system volume, as in
XPDec -v 1234-ABCD
(The volume serial number is part of the 'dir' command's output.)
>>>> XPDec -m
This option calculates the network adapter bit-field value
corresponding to the given MAC address. Similar to '-v' this option
was implemented as a proof of concept.
The only argument needed for the '-m' option is the MAC address of
your network adapter, as in
XPDec -m 00-C0-DF-08-9E-44
(Use the 'route print' command to obtain the MAC address of your
network adapter.)
>> HARDWARE MODIFICATIONS
When looking at the effects of hardware modifications on an already
activated installation of Windows XP, the file 'wpa.dbl' in the
'system32' directory plays a central role. It is a simple
RC4-encrypted database that stores, among other things like expiration
information and the Confirmation ID of an activated installation,
a) the bit-field values representing the current hardware
configuration,
and
b) the bit-field values representing the hardware configuration
at the time of product activation.
While a) is automatically updated each time the hardware configuration
is modified in order to reflect the changes, b) remains fixed. Hence,
b) can be thought of as a snapshot of the hardware configuration at
the time of product activation.
This snapshot does not exist in the database before product activation
and if we compare the size of 'wpa.dbl' before and after activation,
we will notice an increased file size. This is because the snapshot is
added to the database.
When judging whether re-activation is necessary, the bit-field values
of a) are compared to the bit-field values of b), i.e. the current
hardware configuration is compared to the hardware configuration at
the time of activation.
>>> Non-dockable computer
Typically all bit-fields with the exception of the unused field and
the 'dockable' field are compared. If more than three of these ten
bit-fields have changed in a) since product activation, re-activation
is required.
This means, for example, that in our above real-world example, we
could replace the harddrive and the CD-ROM drive and substantially
upgrade our RAM without having to re-activate our Windows XP
installation.
However, if we completely re-installed Windows XP, the information in
b) would be lost and we would have to re-activate our installation,
even if we had not changed our hardware.
>>> Dockable computer
If bit 31 of H2 indicates that our computer supports a docking
station, however, only seven of the ten bit-fields mentioned above are
compared. The bit-fields corresponding to the SCSI host adapter, the
IDE controller, and the graphics board are omitted. But again, of
these remaining seven bit-fields, only up to three may change without
requiring re-activation.
>> CONCLUSIONS
In this paper we have given a technical overview of Windows Product
Activation as implemented in Windows XP. We have shown what
information the data transmitted during product activation is derived
from and how hardware upgrades affect an already activated
installation.
Looking at the technical details of WPA, we do not think that it is as
problematic as many people have expected. We think so, because WPA is
tolerant with respect to hardware modifications. In addition, it is
likely that more than one hardware component map to a certain value
for a given bit-field. From the above real-world example we know that
the PX-32TS maps to the value 0x37 = 55. But there are probably many
other CD-ROM drives that map to the same value. Hence, it is
impossible to tell from the bit-field value whether it is a PX-32TS
that we are using or one of the other drives that map to the same
value.
In contrast to many critics of Windows Product Activation, we think
that WPA does not prevent typical hardware modifications and,
moreover, respects the user's right to privacy.
>> ABOUT THE AUTHORS
Fully Licensed GmbH is a start-up company focusing on novel approaches
to online software licensing and distribution. Have a look at their
website at
http://www.licenturion.com
for more information.
Their research branch every now and then analyzes licensing solutions
implemented by other companies.
>> COPYRIGHT
Copyright (C) 2001 Fully Licensed GmbH (www.licenturion.com)
All rights reserved.
You are free to do whatever you want with this paper. However, you
have to supply the URL of its online version
http://www.licenturion.com/xp/
with any work derived from this paper to give credit to its authors.
-------------- next part --------------
>>
>> Frequently asked questions and their answers
>> concerning the Fully Licensed WPA paper
>>
>> Fully Licensed GmbH, July 10, 2001
>>
>> 1. Was Microsoft involved in the creation of the paper?
Microsoft was not involved in the creation of the paper in any
way. However, we made a draft version available to Microsoft to give
them a head-start. We consider it to be good etiquette to inform a
vendor of a pending publication related to one his or her products, so
that the vendor is able to prepare an official response.
>> 2. Why should we believe you?
We do not expect you to believe us. That's why we have provided our
complete knowledge about WPA and the XPDec utility. Combine both to
verify our claims.
>> 3. But Thomas Lopatic, one of your managing directors was born in
Unterschleissheim, Germany, which is the town near Munich in
which Microsoft's European headquarters are located.
This is a nice coincidence. It is in a way understandable - and at the
same time highly amusing to us :-) - that this has given rise to
rumors about the whole paper being a cleverly planned Microsoft
conspiracy.
Thomas was actually born in Karlsruhe, Germany. However, he was living
in Unterschleissheim from the 1970s - i.e. long before Microsoft moved
there - until recently, when he moved to Berlin. That's why some
records still list Unterschleissheim as the place where he
lives. Incorrectly interpreting these records led to the rumor that
Thomas was born in Unterschleissheim.
>> 4. Does Microsoft downplay the paper?
No, most definitely not. The paper really IS harmless. It does not
provide any information that would help a pirate circumvent WPA.
>> 5. Why did you release details on Windows Product Activation?
We felt that there is a need for facts in the debate about Windows
Product Activation. Many people suspected that WPA could be abused to
spy on end-users. Our paper, however, shows that insensitive
information is transmitted during product activation. From this, it
can be seen that the facts that we provide really are a necessary
contribution to the ongoing discussion about WPA.
We think that license enforcement mechanisms will be an important part
of the future of software distribution via the Internet. Thus, we do
think that public discussion of technology of this kind must be free
from bias and it must be based on facts and openness.
We hope that the information that we provide positively affects the
current debate. The debate is necessary, but it should be based on
facts and full disclosure of information relevant to the privacy
question.
>> 6. Do you know how to circumvent Windows Product Activation?
No. We provide insight into which information is transmitted to
Microsoft during activation. Our paper is important to help people
understand the impact of WPA on their work and their privacy. We do
not believe that our paper helps in any way to circumvent the license
enforcement provided by WPA.
>> 7. Your paper says that Microsoft will err on the user's side.
What our paper shows is that a) no sensitive information is
transferred to Microsoft and b) typical hardware upgrades do not
negatively affect an already activated installation of Windows XP.
But, if you either completely re-install Windows XP or modify your
hardware beyond what is tolerated by product activation, you have to
re-activate Windows XP.
The important question now is: How often will Microsoft let you
re-activate? Erring on the user's side would mean that they allow you
to re-activate as often as you like, which seems to be what Microsoft
says they will do.
It is, however, impossible to confirm this policy by means of a
technical analysis.
>> 8. Why doesn't Microsoft know which hardware I use?
Let us consider the case of IDE controllers. In the installation ID
transmitted to Microsoft they are represented by a 4-bit value. The 4
bits are obtained by applying the MD5 message digest algorithm to a
string that uniquely identifies the vendor and model of the IDE
controller, e.g.
'PCI\VEN_8086&DEV_7111&SUBSYS_00000000&REV_01'
and picking 4 bits from fixed locations in the resulting 128-bit
message digest.
With 4 bits, we can represent 16 different values at maximum. However,
there are far more than 16 different models of IDE controllers out
there. So, since there are more models than 4-bit values, the above
hashing procedure must yield the same 4 bits for more than one
model. The more models there are, the more models will map to a given
4-bit value.
In contrast to what Microsoft says, the privacy that WPA provides is
not based on the assumption that it is impossible to invert the
employed message digest algorithm, i.e. MD5. If we used all 128 bits
of the message digest derived from a hardware component's
identification string, this 128-bit value would most probably uniquely
identify the hardware component. If we used 128 bits, each hardware
component on earth would probably map to a different value.
What an attacker would then do is build a list of all hardware
components on this planet and calculate the corresponding 128-bit
values, which are probably all different. Then finding the hardware
component that corresponds to a certain 128-bit value is just a table
lookup away.
Privacy is based on the fact that only a few bits of the resulting
128-bit message digest are considered. Obviously this leads to lots of
collisions, i.e. lots of hardware components mapping to a given
value. If there were 160 different models of IDE controllers, we could
on average expect 160 / 16 = 10 models to map to the same 4-bit value.
Let us, as another example, consider the MAC address of an ethernet
adapter. The discussion is technically not 100% accurate, but it
illustrates the point. The MAC address is a 48-bit value, which means
that it can theoretically be one of 281,474,976,710,656 different
values. However, its 10-bit representation in the Installation ID is
obtained by picking 10 bits from the MD5 hash over an ASCII string
comprised of the 12 hex digits of the 48-bit value. Picking 10 bits
leads to 1,024 different results at maximum.
So, on average, we expect
281,474,976,710,656 / 1,024 = 274,877,906,944
MAC addresses to map to the same 10-bit value. Because of this, nobody
will be able to obtain the actual MAC address from the 10-bit value,
since there are 274,877,906,944 candidate MAC addresses from which the
10-bit value could have been derived.
It is interesting to see that the bit-field that represents the MAC
address is 10 bits in size, while the bit-field representing the IDE
controller only consists of 4 bits. Microsoft probably have assigned a
longer bit-field to a component if they expect more diversity in the
identification string of this component. The number of different IDE
controller models is smaller by orders of magnitude than the number of
different MAC addresses. So, to produce sufficient collisions, they
decided to use a relatively small bit-field for IDE controllers but
could still afford to chose a 10-bit bit-field in the case of MAC
addresses.
>> 9. What are the implications of re-activating after hardware
changes?
This is an interesting issue which is not covered in our paper. We
simply did not think of it. Our mistake. It was brought to our
attention by an article by Greg Falcon <veloso at verylowsodium.com> on
www.slashdot.org: If you have to re-activate your installation of
Windows XP because of hardware modifications, your new hardware
configuration is embedded in the Installation ID in the form discussed
above. While this does not enable anyone to find out which components
you have, it is trivial to find out which components you have
changed. Just examine which bit-fields have changed their value since
the original activation.
More information about the reader-list
mailing list