On Wed, Jun 14, 2006 at 08:52:01PM -0700, Wolfgang S. Rupprecht wrote:
| So what if one of the driver writers for one of the open source operating
| systems were to design a set of open standards for a hardware/software
| interface for chipsets in this class.
|
| I guess the part I don't understand is why are open source folks so
| wary of running black-box *.o binaries from a vendor but are quite
| eager to use blackbox crypto cards (that effectively run blackbox *.o
| firmware)?
Don't assume that everyone is even willing to hand over their private
data to some sealed black box. There are, of course, a number of
differences. What runs on the card/chip generally won't have access
to the rest of the system (assuming reasonable bus security, which may
not be true). But a *.o binary driver will have that access to the
level it is installed (probably the kernel, which means it has access
to everything). Bugs in the *.o could crash or hang the kernel if it
is there. But in the card/chip it is less likely to cause damage,
although that isn't impossible (could lock up the bus). I'd be a bit
more trusting of a crypto device that was connected via some soft means
like an ethernet. But that still implies a (possibly misplaced) trust
in the ethernet card itself.
Then there is the issue of whether they provide kernel level *.o files
for all the platforms OpenBSD and other systems support.
| While I don't think these cards really do contain trojans, they
| certainly could at some point in the future. What prevents the
| manufacturers from storing all keys into some on-chip nv-ram for later
| retrieval? Ditto for the card intentionally leaking the keying data
| into the cipher stream? At one point during the cold-war it certainly
| seemed like the US did manage to slip a leaky key trojan into a well
| respected company's cipher system.
Similar risk could exist in CPU based crypto instructions, too, if such
a CPU were to be made public.
Ultimately, I'll personally depend on crypto in software I can access for
myself. I think that's your real point.
FYI, I don't even trust Theo for writing safe crypto software. But that's
not a personal statement ... it's just a statement of procedure; I would
not trust anyone, period. The big advantage of open source that we all
already know is the many eyes (with no conflict of interest) aspect.
That cannot be said for either binary software or hardware implementations.
What interests me among Hifn's chips are not the crypto capabilities, but
the compression capabilities. No export regulations for that as long as
it doesn't have the crypto in it, so those should be fully open (I have
not checked) as to interface and interoperability (e.g. uses a standard
compression format). Even data compression in a sealed box has risks,
such as it detecting actual keys being moved around in the clear and saving
them into NVRAM. How do you know your CPU doesn't have this?
