Ed Gerck <egerck(_at_)laser(_dot_)cps(_dot_)softex(_dot_)br> writes:
On 30 Dec 1997, EKR wrote:
-> Ed Gerck <egerck(_at_)laser(_dot_)cps(_dot_)softex(_dot_)br> writes:
-> > 1. It is clear that S/MIME does not intend to be a high-security standard
-> > (such as could be used for banking purposes, for company-critical
-> > information exchange, etc.), when you see for example the various
-> > documented security holes that already exist and are simply discarded (to
-> > name a few, the potential "trojan horse" situation of S/MIME private-key
-> > generation in MSIE, the "on-line" S/MIME private-key generation with the
-> > CA in the same session as used in NS Communicator, the question of no
user
-> > choice in the random seed generation for S/MIME private-key generation in
-> > either case, the S/MIME use of self-signed certs, the possibility of
-> > traceless S/MIME private-key snatching with an ActiveX control, etc.).
->
-> AAAAH. These aren't security holes in S/MIME. They're security holes in
-> S/MIME implementations.
I disagree, because the security holes mentioned are perfectly allowed by
the S/MIME standard. So, such implementations are 100% S/MIME-compliant
-- which they should never be if the standard would aim at a higher
security level.
That doesn't mean that S/MIME can't be used for high security
purposes. It merely means that it can be used in situations where
those requirements aren't met as well. On the other hand, if you
want to meet requirements like that, you can do so using S/MIME.
->S/MIME the protocol is perfectly usable in
-> high security situations. As always, the implementation has to
-> be secure. (Incidentally, all the security holes you mention with
-> the exception of self-signed certs are easily solved by using a
-> secure hardware token for one's own private keying material.)
I must again disagree. It is a common misconception that a third-party
manufactured hardware token would magically infuse trust into the final
result of a cryptographic calculation. As we know, trapdoors can be easily
inserted into the calculation of keys or signatures, arguably more
stealthly in a hardware token with concealed and secret source code.
This misses the point entirely. I'm not suggesting that a hardware
is a magic bullet. I'm merely observing that suitably designed
hardware tokens (of which several are available) can solve the
implementation problems you were complaining about. In fact,
hardware is quite a common requirement in certain environments
for precisely that reason.
That said, the issue of trapdoors is a red herring. Ultimately
you have to trust your vendor not to intentionally compromise your
security--or do it all yourself. Read "Reflections On Trusting Trust"
for an example that makes this point quite clearly.
-Ekr
--
[Eric Rescorla Terisa Systems, Inc.]
"Put it in the top slot."