Re: Faster way to deescrow Clipper

Could someone please enlighten me on this: It seems from the descriptions
of the hack to fake a LEAF that 1) When two Clipper chips are going to
communicate, one of them generates the session key and sends a LEAF to the
other chip, 2) The second chip recognizes the LEAF as being valid based on
the validity of the checksum, but does not determine the session key from
the LEAF.

If that's the case, then 1) How does the second chip find out what the
session key is? 2) Doesn't the second chip also have to generate and send a
LEAF, if for no other reason than to identify itself to the wiretappers,
and if so won't that give away the session key if that chip's device is not
also hacked? 3) If all that is needed for this hack is a LEAF with a proper
checksum, why go through the brute force method of generating random LEAFs?
Why not just buy (or steal or whatever) another Clippered device that you
never use for real communication so the wiretappers have no record of who
has that serial number, and get LEAFs from it? For that matter, why can't
you obtain one LEAF from listening to anybody's Clippered transmission and
use it over and over again?

It can't be *that* simple, can it?

 -- sidney <sidney@taurus.apple.com>

Allow me to clear up a major misconception here, which I initially
shared. According to Matt, the cleartext of the session key and the IV
are both components that go into the checksum. Therefore, the remote
EES unit CAN determine that you've spoofed them if you attempt a
shortcut like reusing a LEAF generated by another unit. You really
have to test lots of pseudoLEAFs against a test unit that you've
handed a session key to.

Perry

Sidney Markowitz says:
> Could someone please enlighten me on this: It seems from the descriptions
> of the hack to fake a LEAF that 1) When two Clipper chips are going to
> communicate, one of them generates the session key and sends a LEAF to the
> other chip, 2) The second chip recognizes the LEAF as being valid based on
> the validity of the checksum, but does not determine the session key from
> the LEAF.

Correct. However, remember that it tests the checksum against an IV
and session key.

> If that's the case, then 1) How does the second chip find out what the
> session key is?

"It depends". Diffie-Hellman, prearrangement, via a public key
mediated exchange, or anything else that seams reasonable.

> 3) If all that is needed for this hack is a LEAF with a proper
> checksum, why go through the brute force method of generating random LEAFs?

See above -- the problem is that of finding a LEAF with a proper
checksum that corresponds to the session key.

Perry