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
participants (2)
-
Perry E. Metzger -
sidney＠taurus.apple.com