[4050] in cryptography@c2.net mail archive
Re: Intel announcements at RSA '99
daemon@ATHENA.MIT.EDU (David R. Conrad)
Fri Jan 22 13:45:09 1999
Date: Fri, 22 Jan 1999 01:21:42 -0500 (EST)
From: "David R. Conrad" <drc@adni.net>
To: Eric Murray <ericm@lne.com>
Cc: cryptography@c2.net
In-Reply-To: <19990121090235.30683@slack.lne.com>
On Thu, 21 Jan 1999, Eric Murray wrote:
[Edited, somewhat.]
> Since PRNGs cycle, with enough output you could tell if a given chip
> is using a PRNG. (assuming that the RNG produces output fast enough
> since good PRNGs have long cycles. You wouldn't have to store all the
> output, just the beginning X bytes to detect the start of the next
> cycle.)
Assuming the period was short enough to do so. With enough state, though,
the period could be long enough that this would be infeasable. Of course,
this is Intel, after all, and so it would probably be designed to have a
period of 2^256 but owing to a bug in an awk script loading some constants
for the algorithm into their design system improperly, it would end up
with the period foreshortened to merely 2^24. Or 2^16, depending on the
phase of the moon.
> You could also correlate output from different
> chips with similar serial numbers, since their seeds would be similar
If they did it right, chips with similar s/n's would have output that
appeared completely unrelated.
> (the secret would probably be a fixed value for large numbers of chips
> since it's pretty expensive to put a unique value like a serial number in
> each chip).
Well, they're already going to that trouble for the s/n's, why not the
secrets? And they're already faced with a database of all the s/n's,
the MHz rating of each, whether it's been reported stolen, and, *gasp*,
maybe even some end-user data. So why not throw one more little field
into that database? In for a penny, in for a pound.
But I expect the RNG in the chips will be good, because, when it comes
right down to it, why bother? There are only two kinds of apps, really:
A) The ones which already have such lousy security that
they can be cracked without feeding them fishy bits
to use as session keys, nonces, and so forth;
B) The ones with (more or less) solid security that are
already doing clever things to come up with good
session keys, and will no doubt only use this RNG,
modulo their own post-whitening, as one _more_
source of entropy to draw from.
The best thing, to me, about the designs of /dev/random and such are that,
owing to their use of one-way hashes, they can't really be hurt by mixing
in "bad" bits; as long as that's the case, any new putative source of
entropy can only help, not hurt.
Or such is my understanding, at least.
> The question I have about Intel's announcement is about the s/n. If
> software vendors use it to ID various bits of software (or as your
> ID into a chat room, the example used by the Intel exec announcing the stuff)
> how are you going to keep hackers from diddling the software that
> calls the chip s/n routine to make it return whatever they want?
Right. If the instruction isn't privileged, you'd have to patch the code.
If the instruction is privileged (or can be made so by frobbing the right
bit in some control register), your OS can emulate it in its "illegal op
code" exception handler.
Hey! You could do that right now, and make it appear that the instruction
exists on older processors!
> ... Some hacks were pretty sophisticated, letting the user
> set the hostid for each process group and supporting numerous
> hostids per real host.
Clever. :-) I also think of the MS-DOS "SETVER" command that appeared in
DOS 4.0 or 5.0. It was a TSR that would catch calls to the "get version
number" DOS function, check whether the program's name was on its list,
and, if so, lie to the program about what version of DOS it was running
under.
Even if the "Get S/N" and "Get RNG bits" instructions aren't privileged,
you could handle them specially *on any processors which lacked them* in
the way I described above.
And then it would be a simple matter to do what you describe above,
returning different s/n's on a per-process or per-process group basis.
The only question would be, could you do the same thing under Windows with
a VXD, or would you have to hack the NT kernel? (But either way, it would
be doable.)
Of course, that still leaves open the question of how you would convince
the app that the instructions were available on an older processor. If it
is indicated simply by some formerly-undefined expected-to-be-zero bit in
the flags, well, you can't exactly make moving the flags into the
accumulator a privileged instruction.
I did a little digging on www.x86.org and didn't come up with anything.
Anyone with further details on this, I would really love to see them.
David R. Conrad <drc@adni.net>
This is why I love America -- that any kid can dream "I'm going to get
naked with the President" ... and that dream can actually come true.
What a great country! -- Michael Moore
