Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!boomer
From: boomer@athena.mit.edu (Don Alvarez)
Newsgroups: comp.protocols.kerberos
Subject: Re: some comments on Kerberos
Summary: application process space must be able to touch your secrets
Message-ID: <11357@bloom-beacon.MIT.EDU>
Date: 11 May 89 22:45:21 GMT
References: <890509181345.2660012a@CCC.MFECC.LLNL.GOV> <8905101146.AA05099@uk.ac.cam.cl.dovey>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: boomer@space.mit.edu (Don Alvarez)
Organization: MIT Center for Space Research
Lines: 55


In article <8905101146.AA05099@uk.ac.cam.cl.dovey>,
jhs%computer-lab.cambridge.ac.uk@NSFNET-RELAY.AC.UK
(Jerome H Saltzer) writes (in reference to posting by Nessett)

>> o  Kerberos keeps its encryption keys in application process space.  
>
>I don't think that is a criticism of Kerberos itself as much as a
>criticism of the way in which Kerberos is implemented in UNIX systems.
>The protocol does not specify where keys should be kept, and in a
>system specially designed for security one might well provide hardware
>or software-in-the-supervisor storage mechanisms for the keys and for
>temporary storage to hold the password.  Addition of such mechanisms
>to UNIX would not require changes in the basic design of Kerberos.  (But
>the changes to UNIX would be extensive enough as to risk considerable
>debate, which is why the current Kerberos implementation didn't try.)


Keys can not be convincingly hidden with current generation hardware.  If
you have no dedicated security hardware, then all your local key
protection must be done in software, with the obvious risks.

Smartcards have received lots of attention, but they exhibit the same
weakness.  There still needs to be some call by which "application
process space" can ask the smartcard to generate tickets for new
services.  It is conceptually no more difficult to massage the kernel
into allowing a fraudulent call than it is to massage the kernel into
divulging a secret key.  

Even if you do give yourself a full dedicated security supervisor
module which watches the main host processor and validates its
actions, then all you are doing is passing the buck to the guy who has
to make sure that the supervisor code doesn't get modified.

Any secrets by which a user validates his actions must pass through
the host (or transceiver, or whatever).  Once he hands his secrets
over to the host, he has no way to force it to use them honorably,
because it knows all the secrets he knows.

The best you can do with secrets is make it very hard for someone to
rewrite the software which protects them.  You can't make them
absolutely safe.  In the limiting case where you are willing to give
me a soldering iron and EPROM programmer, the only way you can protect
your secrets is by never logging in.



(for an interesting example, note that all retina recognition does is
prove that you are sitting at your terminal...it can't prove that you
were the one who stuffed 'rm *.*' into the keyboard buffer)
--
+ -------------------------------------------------------------------------- +
|  Don Alvarez           M.I.T. Center For Space Research   (617) 253-7457   |
|  boomer@SPACE.MIT.EDU  coming soon: Princeton University Dept. of Physics  |
+ -------------------------------------------------------------------------- +