[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: key management
in reply to many messages on mutual suspicion on a multi-user host:
Sigh! I tried to give a simple answer to a simple question about
mutual suspicion on a multi-user host, and the feedback just gets
more and more complex about issues that weren't even in the original
question and answer. I guess I wasn't communicating clearly enough,
so let me try again from the top.
Rather than trying to address each point, let me restate what I was
trying to say which was VERY SIMPLE.
The original question was:
>>
>>2) Mutually distrustful users on a single host CANNOT be trusted to
>>know each others keys. Systems that use host keying conflate
>>different users cryptographic keys, making all sorts of unfortunate
>>attacks possible. Preventing seperate users from using each others
>>keys is necessary.
>
>How do you propose for mutually suspicious users to use
>the same host?
What I was trying to say was:
If you have mutual suspicion on a multi-user host, you can only achieve
security by trusting the operating system to keep things separate and
mediated. No matter what you do cryptographically on the networking
protocols, you must trust the operating system, because it is holding
your cleartext data and might be holding the cryptographic keys as well.
I was not implying any particular orange book level, nor was I implying
that a trusted operating system was sufficient (by itself) for resolving
mutual suspicion in a multi-user system that is networked. Only that a
trusted operating system is NECESSARY.
If you don't have a trustworthy operating system, you are in deep trouble.
Unfortunately, there are VERY FEW trustworthy operating systems out there.
That was all I was trying to say. Now, let me add a couple of points
beyond what I was saying originally.
There are also cryptographic implications of the need for a trusted
operating system. If you can trust the operating system (and you have to!),
then all traffic between a given pair of systems might as well be under
the same key, because even if separate session keys are used for each user,
the operating systems at each end can intermingle the cleartext, if they
so choose. (This assumes that the crypto system is immune to chosen
plaintext attack. If it is NOT immune to chosen plaintext, then using
a single key for a pair of systems is a bad thing, as Perry pointed out.)
(This also assumes
that the operating systems and/or crypto hardware devices don't make
the keys visible to the users.) Digital's ethernet encryption device
(DESNC) was designed in exactly this way. Keys were negotiated on
a per-host-pair basis for all users on those hosts. Keys always remained
inside the DESNC hardware boxes, so users never saw the keys. The
assumption was that DES was sufficiently resistent to chosen plaintext
attack for the application domain of DESNC.
Note that if two mutually suspicious users are both communicating between
the same pair of systems, they have to trust BOTH operating systems. Even
if the crypto protocols use separate keys for each session, the operating
systems on either end can compromise the cleartext data.
If users and/or user-mode software has access to the crypto keys, then
the problems get even worse, because any Trojan horse or virus therefore
could have access to the keys.
I hope this helps understand my comments.
Paul
References: