Re: ESP Unix encrypted session protocol software

At 10:02 AM 1/30/95, Matt Blaze wrote:
....>As for the alternatives, I think the picture is pretty bleak, to tell
>the truth.  The cryptographically sound way to prevent spoofing is
>with authentication of the agreed key.  But for the remote host to
>authenticate itself, it has to have a secret signature key.  Where to
>store it?  A typical machine, especially a multi-user, unattended server
>simply has no safe place to store keys.
....
There would be on a secure "multi-user, unattended server". They are not
easy to come by and they arn't really Unix. I don't get on my soap box very
often but I couldn't resist your execelent opportunity. I think that
security requires good crypto and good OS security. There are Orange book
rated systems that are rated to run hostile software in the same machine
with Top Secret information.

>At 10:02 AM 1/30/95, Matt Blaze wrote:
>....>As for the alternatives, I think the picture is pretty bleak, to tell
>>the truth.  The cryptographically sound way to prevent spoofing is
>>with authentication of the agreed key.  But for the remote host to
>>authenticate itself, it has to have a secret signature key.  Where to
>>store it?  A typical machine, especially a multi-user, unattended server
>>simply has no safe place to store keys.
>....
>There would be on a secure "multi-user, unattended server". They are not
>easy to come by and they arn't really Unix. I don't get on my soap box very
>often but I couldn't resist your execelent opportunity. I think that
>security requires good crypto and good OS security. There are Orange book
>rated systems that are rated to run hostile software in the same machine
>with Top Secret information.
>
>

Sure, but as you point out in your second sentence, systems that are
secure enough for secret storage aren't exactly "typical" of what's out
there on the Internet.  And even an Orange book A rated system has to
be kept locked up, under guard and administered properly if you want to
be sure that the secret data stored on it remain secret.

The vast majority of unattended "server" machines in my online life are
neither located in well-controlled environments (especially considering
backup tapes) nor administered particularly well.  I'm not sure that
persistent signature keys stored on such hosts provide much extra
assurance of machine identity beyond what already comes from their
answering to the expected IP address (which is hardly saying much, of
course).  I think better than expecting the world to switch over to
cumbersome, multilevel secure OSs is to equip such servers with
inexpensive tamper-resistant cryptographic modules that never reveal
their secrets.  At least then you're guaranteed that there can be only
one instance of a machine's identity out there at a time, and have some
hope of detecting the theft of the key material.  (There may be some
hope on this front.  PCMCIA crypto modules like the NS iPower card are
beginning to hit the market already, and products like that may well be
commonplace by the time host authentication protocols start to be
deployed for real on the Internet.)

From: Matt Blaze <mab@research.att.com>

   I think better than expecting the world to switch over to
   cumbersome, multilevel secure OSs is to equip such servers with
   inexpensive tamper-resistant cryptographic modules that never reveal
   their secrets.

This is certainly the first step to take, even if it's not a complete
answer.

   At least then you're guaranteed that there can be only
   one instance of a machine's identity out there at a time, and have some
   hope of detecting the theft of the key material.  

Unfortunately, this isn't really true.

Let's take as our model general purpose computers which can't store
secrets connected directly to crypto modules which can.  Furthermore,
let us assume that these general purpose computer are subject to
intrusion.  In other words, it's today's servers with attached crypto.

Now, the crypto module can't authenticate the machine it's plugged
into, because, by definition, that machine can't keep a secret.  One
ends up in an infinite regress here in one tries to assume a secret in
the place we have assumed otherwise.  Because the crypto module can't
authenticate the machine, it will reply to service requests from both
the local and approved machine and any remote and unapproved machines
that can gain access to the module.  The software on the server can be
subverted in order to allow the local crypto module to service remote
requests.

The attack works like this.  First, subvert the system software on
some server, probably through existing implementation defects.  Now,
install new software on that server that allows other machines to make
remote procedure calls to the module.  Set up a client on an
impersonating machine that make remote calls to the subverted server
whenever it needs to spoof.  The remote calls will most likely be an
encrypted protocol, to boot.  The easiest way to detect this
externally will be an additional delay in response, that is, doable
but not particularly reliable.

This is not to say that crypto modules are useless.  They have a great
use in recovery.  Because the secret doesn't leave the module, you
have an assurance after recovery (reboot from CDROM, for example) that
nobody else has the secret.  There won't be a need for an immediate
key change, at least.  What you don't get is a complete loss of
assurance of identity.

The prevalent use of modules further reduces the likelihood of initial
attacks based on spoofing.  Since active IP attacks require the
subversion of routers, and since router software is much more
difficult to subvert than general purpose servers, adding crypto
modules to routers would be a big win.

Eric

From: Matt Blaze <mab@research.att.com>
On Tue, 31 Jan 1995, Eric Hughes wrote:
> Let's take as our model general purpose computers which can't store
> secrets connected directly to crypto modules which can.  Furthermore,
> let us assume that these general purpose computer are subject to
> intrusion.  In other words, it's today's servers with attached crypto.
> 
> Now, the crypto module can't authenticate the machine it's plugged
> into, because, by definition, that machine can't keep a secret.

The model does not work, because that is not what we
want to do.

True:  Matt's proposal cannot authenticate a machine.  But
one does not really want to authenticate a machine.  One
wants to authenticate data, that one might choose
to transmit from that machine.  For this purpose a 
tamper resistant crypto module that can be connected 
to a machine, but which is under user
control, not under the control of the machine, is the
only totally bullet proof solution.

Of course expensive tamper proof crypto modules already exist:  A 
Dos computer in a room with a key, running virtually no 
network software and possessing almost no utilities, though
doubtless what Matt had in mind was a PCI card that one
could keep in ones wallet.

> The prevalent use of modules further reduces the likelihood of initial
> attacks based on spoofing.  Since active IP attacks require the
> subversion of routers, and since router software is much more
> difficult to subvert than general purpose servers, adding crypto
> modules to routers would be a big win.

This does not make sense:  The advantage of a tamper resistant module
is that if somebody physically gets to the system, he still cannot
get the key.  But if he physically gets to the router, he can
make it do his will, even if he does not get the key.  So one
might as well have the key in software in the router.

If the router is hard to subvert, and the attacker cannot 
physically get to it, then there is little need for a separate
tamper resistant module.  Software will do fine.

If the router can be got at, you are stuffed regardless, tamper
resistant module or not.

 ---------------------------------------------------------------------
                                          |  
We have the right to defend ourselves     |   http://www.catalog.com/jamesd/
and our property, because of the kind     |  
of animals that we are. True law          |   James A. Donald
derives from this right, not from the     |  
arbitrary power of the omnipotent state.  |   jamesd@netcom.com

>> The prevalent use of modules further reduces the likelihood of initial
>> attacks based on spoofing.  Since active IP attacks require the
>> subversion of routers, and since router software is much more
>> difficult to subvert than general purpose servers, adding crypto
>> modules to routers would be a big win.
>
>This does not make sense:  The advantage of a tamper resistant module
>is that if somebody physically gets to the system, he still cannot
>get the key.  But if he physically gets to the router, he can
>make it do his will, even if he does not get the key.  So one
>might as well have the key in software in the router.
>
>If the router is hard to subvert, and the attacker cannot 
>physically get to it, then there is little need for a separate
>tamper resistant module.  Software will do fine.
>
>If the router can be got at, you are stuffed regardless, tamper
>resistant module or not.

The advantage of a secure crypto module on an insecure server (or
router or whatever) is in limiting the scope of successful attack. 
As Eric pointed out, if you can subvert a general purpose machine that
does all its crypto through a secure module that you can't subvert,
you can still add a covert "service" to the machine that lets
a future spoofer use the module remotely.  The main important
difference between this attack and just learning the server's secret
is that it only remains useful as long as the attack is undiscovered.
In the case of software keys, it is sufficient for the attacker to subvert
the machine that knows the secret ONCE.  He or she can put things back
to normal on the original machine and still know the secret forever, with
little chance of future detection.  With a secure module, the attacker has
to either steal (physically) the hardware (which will be discovered when
the real server stops working) or set up the kind of future access that
Eric mentioned (which, once discovered, will likely be turned off or
investigated).

If you have secure crypto hardware, you only have to worry about and
detect whether the server is being compromised continuously.  Otherwise,
without special hardware, you have to worry about and detect whether the
server was ever compromised since it was last rekeyed.  Personally,
the former seems like a realistic thing to try to do while the latter
doesn't, at least in the environments in which I live.

If the server hardware or software is insecure, cryptographic techniques
can't provide any absolute guarantees, period.   In the real world, though,
you're not interested in absolute guarantees, you just want to
reduce risks.   How effective the mechanisms to do this are depends on
how accurately they reflect the real world threats.

-matt

The advantage of a secure crypto module on an insecure server (or
   router or whatever) is in limiting the scope of successful attack. 

Just to expand on this, the scope is limited in _time_, not space.
That's, when you pull out the module (literally or figuratively), the
attack is known to be over -- and don't plug it back into a machine of
unknown state.

   The main important
   difference between this attack and just learning the server's secret
   is that it only remains useful as long as the attack is undiscovered.

Yes.  Typically, once the attack is discovered, the method used in the
attack is also discovered.  The particular hole is then patched.  The
system can now be put back online without fear of immediate
re-compromise.

Eric

Matt and Cypherpunks, etal.

I have been designing secure crypto modules for many years.  The
primary difficulty has been getting anyone to shell out the money to
buy them.  Perhaps things will be different with PC Cards.

Peace. Tom