[3468] in cryptography@c2.net mail archive
Re: IP: State Govt Will Use Datakey Smart Cards
daemon@ATHENA.MIT.EDU (EKR)
Wed Oct 14 18:43:04 1998
To: "Arnold G. Reinhold" <reinhold@world.std.com>
Cc: "Enzo Michelangeli" <em@who.net>, <cryptography@c2.net>
From: EKR <ekr@rtfm.com>
Date: 14 Oct 1998 15:26:09 -0700
In-Reply-To: "Arnold G. Reinhold"'s message of "Wed, 14 Oct 1998 14:09:34 +0100"
"Arnold G. Reinhold" <reinhold@world.std.com> writes:
> At 9:13 AM -0700 10/14/98, EKR wrote:
> >"Arnold G. Reinhold" <reinhold@world.std.com> writes:
> >>>
> >> The problem is the "hardware-based RNG." Without reverse engineering the
> >> smart card, it is hard to distinguish a fair RNG from one that is rigged to
> >> generate sequences with a much smaller entropy. One approach might be to
> >> have a completely deterministic smart card with no random number generator
> >> at all. Here is how that might work.
> >>
> >> One of my pet ideas is generating public/private key pairs directly from a
> >> passphrase. All one needs to do is transform the passphrase to a binary
> >> number, possibly using a hash function like SHA, and then add that number
> >> to some base number to create a starting point for the prime search
> >> algorithm. Use a different hash value, say after permuting the passphrase,
> >> to start looking for the second prime. Now this approach is probably not
> >> suited for mass audiences who cannot be depended on to use strong
> >> passphrases, but it does have some interesting properties, including the
> >> ability for someone to "memorize" their private key.
> >As has been widely observed, if you're using any of the discrete
> >log systems (DH, DSS, KEA, etc.) the primes are public and the
> >passphrase can be used directly as the private key.
> >
> Good point.
>
> >That said, I don't consider this to be a serious problem. If the
> >manufaturer of your hardware has intentionally compromised it,
> >you're in big trouble. For instance, the hardware can leak your
> >key bits using whatever other random (padding, MEK, etc.) bits
> >it generates.
> >
>
> Depends on what you mean by serious problem. This question isn't keeping me
> awake nights, but I believe designing crypto systems that minimize the
> number of agents you have to trust is a worthwhile goal. For high value
> systems, needing to trust ones hardware manufacturer could be an
> unacceptable risk.
Then you might as well give up, IMHO. There are just too many ways
the hardware manufacturer can screw you over.
> Methods to eliminate that risk are at least worth
> discussing.
>
> For example, it might make sense to separate the RNG from the rest of the
> smart card, perhaps as a detachable submodule. The smart card could then be
> audited by supplying a known bit stream to the RNG input and verifying that
> all outputs followed published algorithmic specs.
Except that there's some special message you can send the card which
puts it into spy mode where it starts leaking. So it shows up fine
under testing but the spooks can compromise it.
I think Reflections on Trusting Trust is the appropriate reference
here.
-Ekr
[Eric Rescorla ekr@rtfm.com]
