[109246] in Cypherpunks
P3 ID Musings
daemon@ATHENA.MIT.EDU (Anonymous)
Sun Mar 14 22:17:03 1999
Date: Mon, 15 Mar 1999 04:03:42 +0100 (CET)
From: Anonymous <nobody@replay.com>
To: cypherpunks@cyberpass.net
Reply-To: Anonymous <nobody@replay.com>
At the 1999 Financial Cryptography conference in Anguilla, Adi Shamir made the
observation that it is impossible to trust today's complex operating systems
and computers. He observed that he would only trust a simple machine that he
knew very well. Shamir's comments and the recent flurry surrounding the
Pentium III identification number or CPUID (0Fh,A2h) instruction started me
thinking about the systems of the past and present.
The 6502 CPU (my functional Commodore VIC still reposes in the closet)
had only eight bits worth or 256 possible operation codes. 56 were actually
used. There were also X and Y index, an accumulator, A, and SP and IP
registers. Instructions themselves could vary from one to three bytes, but the
other one or two bytes were addresses. With only 256 possible opcodes it was
possible to exhaustively explore the space and several people, who bothered to
investigate, found unsupported opcodes that actually did something useful. I
don't have the references or names anymore. This was long ago and far, far away
in another galaxy with no multiply instruction.
Now, Pentium opcodes are two bytes long and there are 65536 of them. Naturally,
very few of these are actually used (http://www.sandpile.org). The Pentium is
vastly more complex than the 6502 and, correspondingly, there is ample room
for exploration (http://www.x86.org) and the discovery of "secret" Intel
opcodes.
Concerning the P3ID, Schneier has observed,
(http://www.zdnet.com/zdnn/stories/comment/0,5859,2194863,00.html ) that a
recipient "has no way of knowing whether the number it gets back is a real ID or
a forged ID" and there is ample opportunity for defeating normal CPUID schemes
of identifying computers and their users.
First, one can always turn the damned thing off. Despite the Zero Knowledge
Systems hack (http://www.zks.net/company/pressrel.asp), it's an easy matter to
add the CPUID turn-off to the boot loader. Since some BIOS allow hardware
protection of the boot sector, once this is accomplished, no hack can restore
the normal CPUID facility on these machines. Karn has released a patch for
Linux to turn of the P3ID feature at boot time
(http://people.qualcomm.com/karn/code/).
Writing utilities that enable the turn-off in the boot loader is what Intel
should have done in the first place and what they should do now if they have
any sense. Even if you don't have such a BIOS you can always find some
anti-virus software that does check boot sector integrity against a stored copy.
Second, one might scan ones' system for programs that implement CPIUD and either
delete the programs, replace the CPUID with NOPs, or with a call to an interrupt
that chains to an interrupt handler, that you have installed, which fakes CPUIDs
results. Of course you would have to apply some intelligence to make sure that
the offending pattern was an actual invocation of CPUID and not some random
occurrence. Such CPUID instructions could be hidden and unwrapped only at run
time but this could be discovered by running everything on a Pentium emulator.
However, all this does not address Shamir's main concern. For example, what
assurance do we have that the complex Pentium does not contain a secret instruction
or instruction sequence that yield the CPU identification number or other
information when the registers are set in a certain way upon execution irrespective
of the CPUID settings. The chances of anyone stumbling upon this facility by accident
are small. It might take two instructions with very different register conditions to
yield this information. Even if it was discovered, Intel could plausibly deny
responsibility by pointing out that they cannot test every possible instruction
sequence in every possible input configuration.
The cozy relationship between chip and some software manufacturers and the US
government, the ease with which it can be hidden and the application of the
canonical threat model implies that such a crypto CPUID instruction exists.
It might be invoked by some common Microsoft executable or DLL, but only under
special circumstances. Perhaps, while processing of some particular sequence of
characters, like "Freedom is not Freeh!" or "Cohen appointed to Microsoft Board
of Directors" in some common string processing function. The output ID would be
encrypted with some secret key known to the government so that one could not
detect its' actual production.
We have no privacy. Get over it or go live in a Faraday cage.
To appear soon: "Steganographic Stenches", Hiding information in BO and common
household odors. Silent and secret communication with both spouse and dog.
- Subcommandante Tamale, Revolutionary and Children's Literature Author with a
30 pound 386 Compaq "portable" running DOS 2.1 near a Jacob's ladder in a Chevy
van traveling at 80 kilometers per hour through the Oakland/Frisco tunnel.
