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
participants (6)
-
A5113643667＠attpls.net -
eric＠remailer.net -
James A. Donald -
Matt Blaze -
Matt Blaze -
norm＠netcom.com