Cryptography Reference
In-Depth Information
long ago. However, it is not always possible to use free software, so that
it's no remedy for all cases.
•
Where asymmetric methods can't help, one might try to use symmetric
methods and distribute the key as described in Section 6.2.1.
•
Cryptographic software should be able to combine modules of
several — ideally competing — vendors. In particular, random generation
should be detached from the program or hardware, because SETUP
systems always use 'disturbed randomness'. However, the user should
be able to see how randomness is processed. All this is possible only if
all internal interfaces are completely disclosed. The more a manufacturer
remains silent about his product's innards, the more mistrustful we should
be about it. I know perfectly well that this requirement is rather utopian.
•
The risk of Trojan cryptography is higher in cryptographic hardware by
definition. You would best create private and public keys outside the
device using publicly checked software (PGP might serve the purpose)
and test for correct processing of the keys in the device based on its
outputs. This might be sufficient when using the RSA method. Suitable
industry standards can be helpful during the test.
•
And finally, an interesting and doable countermeasure is the cascading
of several devices from different manufacturers, similar to the software
modularity mentioned above. Drawbacks are higher costs and perhaps
lower performance.
Like I said earlier, these are just ideas about countermeasures. I hope that more
solutions will be published in the years to come, and I mainly hope that this
potentially very serious threat will be perceived on a broad level.
