From: jyanowitz@hamp.hampshire.edu
Subject: Re: Secure shell by mail
Organization: Hampshire College
Distribution: usa
Date: Wed, 14 Oct 1992 13:09:30 GMT

In article <1992Oct14.070634.12298@sfu.ca>, howesb@monashee.sfu.ca (Charles Howes) writes:
> In article <1bfo95INN6a4@nym.ossi.com> aegl@ossi.com (Tony Luck) writes:
>>barmar@think.com (Barry Margolin) writes:
>>>In article <1992Oct13.172459.28720@zip.eecs.umich.edu> ayman@eecs.umich.edu (Ayman I. Kayssi) writes:
>>>>I posted a question on comp.unix.questions about how to get a shell by email,
>>>>that is a shell that would execute what's in the body of an email message.
>>>>All the details have been worked out except for one thing: security.
>>
>>>How about this:
>>
>>>Include in the header a string in both plaintext and encrypted form.  The
>>>receiving system would decrypt the encrypted form and compare it to the
>>>plaintext.
>>
>>>One problem with this is that it's quite amenable to known-plaintext
>>>attacks.  And it also requires a decryption key to be stored on the
>>>destination system, unless you use a public-key encryption system.
>>
>>Such a system would be easily spoofed by a "replay" attack.  If I ever get
>>hold of one of the messages, I just take the header (which has a valid key
>>on it) attach a different shell script, and send it!  Bang!
> 
> How about encode a sequence number, and disallow repeated sequence numbers?
> 
> The replay attack goes away.  However, a sysop on the route your message
> travels could copy your message, replace the commands, and send his message
> *before* your message.  Significantly harder, but it's not A1 security.
Why not have:
1) A RSA key ssytem for the messages.  The system has a public
and a private key.  You publish the public key, but only the
system knows the private key.  Then people encrypt a message
and email it to the system the system decodes it.  In some fixed
format, like the first 128 bytes, is a key that gives a certain
amount of access, and then the message.

Some major flaws:
1) Keeping the computer's private key secure on the system.
Obviously keep it encrypted on disk, but the key has to reside
somewhere (either in RAM or in some ROOT area) and as soon
as someone finds it, intercepts a message, they know the
key.  Solution:

The computer doesn't need it's own key system, all it needs is the
public keys of everyone allowed to use the system (and each
public key can be tied to a certain level of access).  Then an
authorized individual writes their commands, signs it with
their private key, and emails it the computer.  As I understand,
you don't care who reads the command set, just so long as only
one person could have sent it so the computer knows it's legit.
The computer gets the file, checks the signature against who it's
supposed to belong to, if all's kosher, executes the commands,
else Alarms and Bells go off.

If you use something like MD5 to create the signed digest (as that's
quicker than RSA encrypting the whole message) it's computationally
infeasible for someone to forge a message.  Here, your major problems
would be insuring vlid key distribution and that the people with keys
keep them secure. 
-- 
Jason
jyanowitz@hamp.hampshire.edu
My PGP 2.0 key is available on request and/or my fingering my account.
I'm collecting keys, please email me yours.  Thanks... <End .sig>
Xref: sparky comp.security.misc:1426 alt.security:4584