ESP Unix encrypted session protocol software
Folks, I'm releasing, for experimental use, source code for a preliminary version of my simple Unix->Unix encrypted terminal session manager, ESP. Basically, ESP provides a pseudo-terminal interface to a local shell session that you can use to establish an encrypted terminal session with a another, remote machine. (See the README file below for usage examples). Once the bugs are shaken out, ESP will become part of my CFS package, which will eventually grow into a larger suite of free, practical tools for secure internetworked computing. At the present time, I'm just releasing a "pre-release" to small groups, including interested folks on the cypherpunks list. I've tested ESP under BSDI and SunOS 4.x; you'll also need RSAREF 2.0 (from rsa.com) to compile it. You're on your own for other platforms. This release is NOT production software; it is by no means "ready for prime time". It's slow (reduces bandwidth by 50% and takes 45 seconds to start up). The user interface needs a bit of work, and you really have to know what's going on to make effective use of it. Future versions of ESP will use a more efficient encoding and will add features like a "palmtop" mode that allows secure remote entry of things like passwords from dumb terminals with the encryption done on a disconnected palmtop machine. I hope to eventually have a PC terminal client as well. This version, however, only supports Unix->Unix terminal sessions. Because of export restrictions (and a large cabal of paranoid, rabid lawyers watching my every move), I'm not able to send ESP out of the US or Canada or make it available by anonymous ftp. Sorry. If you want a copy of the ESP-beta sources, send an Email message to cfs@research.att.com (NOT mab@research.att.com) telling me the following: - that you're in the US or Canada, and - that you're a US or Canadian citizen or legal permanent resident, and - that you've read and understand the license and export conditions in the README file below. Remember, you also need to get RSAREF 2.0 to build ESP. -matt ========================= ESP README ============================== This is Version 0.5c (BETA) of ESP, the Encrypted Session Protocol. * The author of this software is Matt Blaze. * Copyright (c) 1995 by AT&T. * Permission to use, copy, and modify this software without fee * is hereby granted, provided that this entire notice is included in * all copies of any software which is or includes a copy or * modification of this software and in all copies of the supporting * documentation for such software. * * This software is subject to United States export controls. * * THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED * WARRANTY. IN PARTICULAR, NEITHER THE AUTHORS NOR AT&T MAKE ANY * REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY * OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE. ESP is an encrypted session protocol layer for managing remote encrypted sessions. It does 1024 bit DH key exchange (from RSAREF) and 3-des in 8bit cfb mode for the traffic encryption. See the man page (esp.1 in this distribution). To compile ESP you'll need the RSAREF 2.0 library, available for free for non-commercial use in the US and Canada from RSA Laboratories (anonymous ftp to rsa.com for details). Once you have RSAREF working, this distribution should compile without problems under SunOS 4.x and BSDI; you're on your own with other platforms. The best way to explain esp is with an example. Here's an encrypted session from alice to bob: alice$ esp ESP v0.5 - encrypted session protocol layer by Matt Blaze, AT&T Bell Labs, January 1995 Randomizing (takes about 45 secs)......................done local layer ready (run 'esp -s' on remote) alice$ rsh bob bob$ ./esp -s ESP v0.5 - encrypted session protocol layer by Matt Blaze, AT&T Bell Labs, January 1995 Randomizing (takes about 45 secs)......................done remote server ready Starting remote side of 1024 bit key exchange. ~~L Starting local key exchange. entering ENCRYPTED mode; type ctrl-^ to escape bob$ ... [encrypted session from alice to bob] ... bob$ exit Press <enter> to return CLEARTEXT mode: bob$ exit alice$ You can also use ESP to provide an encrypted login session; simply create a user "esp" with "esp -s -e login" as the login shell. (Getting this to work properly will require some tweaking on your local system). Run esp -l on the local machine and from there log in to the esp account on the remote machine. Such a configuration encrypts the real account name and password over the network: alice$ esp ESP v0.5 - encrypted session protocol layer by Matt Blaze, AT&T Bell Labs, January 1995 Randomizing (takes about 45 secs)......................done local layer ready (run 'esp -s' on remote) alice$ telnet bob Trying 123.45.67.12... Connected to bob Escape character is '^]'. bob login: esp ESP v0.5 - encrypted session protocol layer by Matt Blaze, AT&T Bell Labs, January 1995 Randomizing (takes about 45 secs)......................done remote server ready Starting remote side of 1024 bit key exchange. ~~L Starting local key exchange. entering ENCRYPTED mode; type ctrl-^ to escape login: mab Password: bob$ ... It's primitive and slow, but seems to work. Comments, bug fixes, ports to new platforms and complaints are welcome. Matt Blaze mab@research.att.com (for esp or cfs questions, use cfs@research.att.com).
On Mon, 30 Jan 1995, Matt Blaze wrote:
ESP is an encrypted session protocol layer for managing remote encrypted sessions. It does 1024 bit DH key exchange (from RSAREF) and 3-des in 8bit cfb mode for the traffic encryption.
I'm curious what Matt and others think about the possibility of the DH key exchange being spoofed by an interloper in this application. -Thomas
On Mon, 30 Jan 1995, Matt Blaze wrote:
ESP is an encrypted session protocol layer for managing remote encrypted sessions. It does 1024 bit DH key exchange (from RSAREF) and 3-des in 8bit cfb mode for the traffic encryption.
I'm curious what Matt and others think about the possibility of the DH key exchange being spoofed by an interloper in this application.
-Thomas
Well, cryptographically speaking, it's trivial for an active attack and probably infeasible for a passive attack. But you knew that... So there are two questions - first, what's the threat model for TCP/IP, and second, what are the alternatives? I'm not sure about the threat model. Spoofing attacks on TCP sessions are not exactly easy - there's a lot to do to pull it off - but not out of the question either (as demonstrated by the recent NYT articles and CERT advisories). Probably the easiest way to receive packets intended for another host is to convince the routing tables between you and your victim to route to you instead of the real host. I'm not aware of this every being done ON PURPOSE, but it's not out of the question, either. 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. And if you had a trusted secure key store on the remote host, you wouldn't really need to use Diffie-Hellman to establish the session key in the first place, since you could just store each user's pre-established session key in advance. At the extreme, fixing this is a Hard Problem. In practice for establishing a reasonably secure session, it all depends on how much you worry about a full-blown (two way) spoofing attack against IP. -matt session ke
On Mon, 30 Jan 1995, Matt Blaze wrote:
And if you had a trusted secure key store on the remote host, you wouldn't really need to use Diffie-Hellman to establish the session key in the first place, since you could just store each user's pre-established session key in advance.
Right - using DH exchange is probably appropriate in situations where there is no pre-established credentials for the party on the other machine. Inter-domain authentication while possible in theory is not often carried out to any great extent in reality. Companies don't trust each other, or at least are not concerned by this lack of security for inter-domain communications. -Thomas
Thomas Grant Edwards says:
Right - using DH exchange is probably appropriate in situations where there is no pre-established credentials for the party on the other machine.
D-H also provides perfect forward secrecy, which is a reason to use it even if there is already an established set of credentials. .pm
Right - using DH exchange is probably appropriate in situations where there is no pre-established credentials for the party on the other machine.
D-H also provides perfect forward secrecy, which is a reason to use it even if there is already an established set of credentials.
How about public-key signing the D-H exchange? Public key to eliminate[*] the man-in-the-middle attack, and D-H for forward secrecy. * Almost eliminate. A sufficiently powerful man in the middle could conceivably subvert the public keys. --apb (Alan Barrett)
From: Matt Blaze <mab@research.att.com> [this = storing secrets] At the extreme, fixing this is a Hard Problem. In practice for establishing a reasonably secure session, it all depends on how much you worry about a full-blown (two way) spoofing attack against IP. I know Matt realizes, but let me repeat for the rest of the list. Just because plain old Diffie Hellman is subject to active attack doesn't mean it's useless. Some protection is better than no protection at all. It's still worthwhile implementing some security to make an opponent's task harder than to implement no security. And just because some people find this level of security inadequate does not mean that everyone else does. Eric
On Tue, 31 Jan 1995, Eric Hughes wrote:
Just because plain old Diffie Hellman is subject to active attack doesn't mean it's useless. Some protection is better than no protection at all. It's still worthwhile implementing some security to make an opponent's task harder than to implement no security.
I'm curious though if there is some way to reduce the risk or at least increase the detectability of active DH spoofing. I am thinking of the use of a trusted adjudicator who could receive information from both the original participants and check to see if the two keys matched. Does anyone see a good solution to this problem? -Thomas
From: Thomas Grant Edwards <tedwards@src.umd.edu> I am thinking of the use of a trusted adjudicator who could receive information from both the original participants and check to see if the two keys matched. How do you authenticate the adjudicator? You'll have to communicate with the adjudicator and verify one of their signatures. You can just as easily exchange signed DH parameters directly with the other party and verify the signature of your correspondent. This is another one of those problems where potential solutions often just lead to infinite regress. Eric
participants (5)
-
Alan Barrett -
eric＠remailer.net -
Matt Blaze -
Perry E. Metzger -
Thomas Grant Edwards