Real-time BBS Encryption??

I thought of this the other day, but don't know enough about programming
and cryptography to do it, or if it actually could be done.  Anyways, I 
figured I'd share it with all of you and see if anyone has any ideas.

Here's the situation:  We all know that some advanced computer systems
have real-time encryption built into all modem connections.  When a 
bank branch dials into the main office the entire transmission may be
encrypted.  This occurs even between terminal connections and the host.
I'm wondering if there is a way to do this with PCs?  Say I'm setting up
a computer bulletin board for my company that is going to run off of a 
DOS PC.  Is there a way to encrypt a remote users entire connection with
the BBS, so that they would have to have a special term program to access
the system?  It would be best if the user only had to load a device driver
or something so that they wouldn't all have to use the same comm program.
Could this be done by loading a special device driver on both the host and
remote so that all data going through com port 2 (or whatever) is encrypted?

Anybody know if something like this is available?



 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
 * Mike McMahon                                                          *
 * Internet:  585-7625@mcimail.com                                       *
 * PGP Fingerprint:  95 F9 2A 1B 81 4F D8 31  56 ED BC A5 4F 64 A7 02    *
 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


> Here's the situation:  We all know that some advanced computer systems
> have real-time encryption built into all modem connections.  When a 
> bank branch dials into the main office the entire transmission may be
> encrypted.  This occurs even between terminal connections and the host.

This is usually accomplished through an external "data encryption unit",
which is interfaced between the terminal (host) and modem. It is NOT in
software.

> I'm wondering if there is a way to do this with PCs? 

Aside from those very expensive high-end boxes that banks use for
their sensative information, there was a DES encryptor made by Practical
Peripherals years ago.  It still may be available.
--

-----BEGIN PGP SIGNED MESSAGE-----

Michael McMahon <uunet!mcimail.com!0005857625> writes:

[Talks about real-time end-to-end encryption of user sessions on BBS's.]

It's not quite as sexy and "James Bond" as real-time end-to-end encryption, 
but I think an easier approach to this would be to adopt the architecture of 
the offline mail-reading programs that are available.

For the benefit of people unaccustomed to offline readers, these programs 
collect up all of the unread messages, E-mails, and file descriptions from a 
BBS, .ZIPs or otherwise packs/compresses the files, and then the user 
downloads that "packet", and hangs up. The user then uses a program on her 
local PC to read and reply to messages in that packet, dials the BBS again, 
and uploads her responses.

I haven't fussed around with offline readers much, but I'll bet it'd be 
pretty simple to add a step to the collection/.ZIP process, which would 
encrypt the whole package with some prearranged key.

This would allow folks to use standard BBS programs, standard terminal 
programs, and perhaps even standard offline readers. It should be pretty 
simple from a programming standpoint, as well; it's perhaps implementable 
with only batch commands. Yes, the "bad guys" will get to watch the user log 
on and log off, and can read the menus and choices - but so what? It's 
possible (easy, really) to encrypt all of the really interesting stuff.

- --
Greg Broiles                            greg@goldenbear.com
Golden Bear Consulting                  +1 503 465 0325
Box 12005 Eugene OR 97440               BBS: +1 503 687 7764



-----BEGIN PGP SIGNATURE-----
Version: 2.2

iQCVAgUBK8R3jH3YhjZY3fMNAQHDagP6AkE+8WrEtSOVNfBDiL6UYplI+TAihl66
IffYPilZ+b9Nxq2VHBF8aUYnX7duLRaivILQ7CPIRsNnKRq3DF5bljcvLY9B9VNn
3SSFSGJFQFYvakElcZPbCGhFbsLdmF8QNN97Z8Cdbx4fGYmj83brNidhHYNeXhpo
5Nk2+5W80mE=
=Yxdd
-----END PGP SIGNATURE-----

[ Info on offline readers ]

>I haven't fussed around with offline readers much, but I'll bet it'd be 
>pretty simple to add a step to the collection/.ZIP process, which would 
>encrypt the whole package with some prearranged key.

     Yes, that's a definite possibility.  Most of the popular offline
readers require that you first send them a packet (usually empty) so that
they will put you in the database.  The reader could just accept a certain
file (pubkey.asc for example) that contains the key you want to be used.
Then all sessions with you will be so encrypted.  Your mail to the BBS could
also be encrypted with the BBS's public key.  Unfortunately, one problem
still exists:  I don't know of too many BBS's where the e-mail messages are
actually encrypted on the disk.  As a matter of fact, the SYSOP can usually
read all mail.

>This would allow folks to use standard BBS programs, standard terminal 
>programs, and perhaps even standard offline readers. It should be pretty 
>simple from a programming standpoint, as well; it's perhaps implementable 
>with only batch commands. Yes, the "bad guys" will get to watch the user log 
>on and log off, and can read the menus and choices - but so what? It's 
>possible (easy, really) to encrypt all of the really interesting stuff.

     Some of those programs (MegaMail, TomCat, etc) run PKUNZIP to unzip the
file(s) then take care of the files themselves.  There isn't an easy way to
throw in encryption.  I would be willing to add an encryption option to my
offline mail software, though.  I have written a UTI (Universal Text
Interface) for ChaelBoard that lets it interface with RelayNet(tm) and
offline mail readers that use UTI's.  I also write a QWK/REP interface that
allows  ChaelBoard to be a node (the hub software isn't quite done yet) on
WildNet and for offline mail reading/replying.  I could implement encryption
in the ZIP/UNZIP step (for the users who have PGP keys registered with the
BBS).

     Do you think it's worth my time?

Chael Hall

--
Chael Hall
nowhere@bsu-cs.bsu.edu, 00CCHALL@BSUVC.BSU.EDU
(317) 285-3648 after 5 pm EST

>I haven't fussed around with offline readers much, but I'll bet it'd be
>pretty simple to add a step to the collection/.ZIP process, which would
>encrypt the whole package with some prearranged key.

that's vulnerable...it's the secret key problem.  The ELEGANT way to do
this with encription is to just make a normal ZIP file, but then build
diffie-hellman into your file downloader (zmodem).  This is also the least
work solution.

SO, since we're talking about offline mail readers...  Whats the best one
for the PC that works (or can easily be made to work) with rfc822 mail
files?  There's pcelm, which sucks...and there's mush, which is slooooow
as hell because of all the overlays.  I was writing my own, but I got
side-tracked...somebody want to save me some programming?

Michael McMahon <0005857625@mcimail.com> writes:
[...]
> I'm wondering if there is a way to do [end-to-end encryption] with PCs?
> Is there a way to encrypt a remote users entire connection with the BBS,
> so that they would have to have a special term program to access the
> system?

Sure, no problem, provided you are willing to do a lot of coding...

The basic idea would be to use public-key encryption to do a short
negotigiation of a one-time key to use for DES/IDEA encryption of the
session.  You could then use a public key for the system as a whole (with
which the users can encrypt thier personal public keys for uploading during
the initial connection) and the user's public key to send the key
transmitted from the BBS for the session.

All that would be necessary is for you to add a bit of code to the comm
program so that it would recognize when it was talking to a system such as
this and do the right thing when needed (the actual encryption code is
readily available in systems like PGP and the various DES implementations
out there.)  The downside is that there are a lot of terminal programs out
there for microcomputers and not many supply source code for such
modifications.  I had thought about using such a system when planning out a
raid-proof 386BSD system and the hassles of trying to get at least one
program to do this for every platform that might want to connect to such a
BBS was more work that I wanted to do.  Perhaps as an option (e.g. one line
using end-to-end encryption and others normal) for connecting to a system,
but if all the lines are done like this you will probably find making it
difficult for people to connect like this keeps people away from the
system.

jim

>> Sure, no problem, provided you are willing to do a lot of coding...

A lot of coding?  You can come very close to doing it with
off-the-shelf code.  ka9q for SLIP.  Telnet authentication is now an
RFC, and encryption will be available probably within a few weeks.

Plus, with IP, you can use existing mechanisms (like POP) to get your
mail on your local PC and do your decryption there.  This is beyond
any PC code I know, and would require new development.

		Marc

Re: encrypting modem links

>I'm wondering if there is a way to do this with PCs?  

Yes, with difficulty, and not transparently.

>Is there a way to encrypt a remote users entire connection with
>the BBS, so that they would have to have a special term program to access
>the system?  

For PC's, replacing the terminal software is really the best way.
There is no effective abstraction of serial port hardware in the PC
world.  The int 0x14 driver in the BIOS was rampantly defective, and
MSDOS does not provide a standard interface.

As a result, almost all comm software on PC's talks to the serial port
directly.  Now in MS Windows, there is abstraction for ther serial
ports, but I don't know how easy it is to insert a device layer.

>It would be best if the user only had to load a device driver
>or something so that they wouldn't all have to use the same comm program.

It might be possible, using a 386, to make a driver that acted as if
it were hardware but actually did encryption.  Ick.  Reliability and
cross-program compatibility would be shit.  And it would have to be
made compatible with whatever else was taking over the 386.

Remember: I hate DOS.

Eric

Eric Hughes wrote:
> >Is there a way to encrypt a remote users entire connection with
> >the BBS, so that they would have to have a special term program to access
> >the system?  
> 
> For PC's, replacing the terminal software is really the best way.
> There is no effective abstraction of serial port hardware in the PC
> world.  The int 0x14 driver in the BIOS was rampantly defective, and
> MSDOS does not provide a standard interface.
> 
> As a result, almost all comm software on PC's talks to the serial port
> directly.  Now in MS Windows, there is abstraction for ther serial
> ports, but I don't know how easy it is to insert a device layer.
> 
> >It would be best if the user only had to load a device driver
> >or something so that they wouldn't all have to use the same comm program.
> 
> It might be possible, using a 386, to make a driver that acted as if
> it were hardware but actually did encryption.  Ick.  Reliability and
> cross-program compatibility would be shit.  And it would have to be
> made compatible with whatever else was taking over the 386.

   Using something like a FOSSIL driver (a replacement serial port driver
that many BBSes use) you could do this.  I would imagine that it would
only encode when carrier is up and the BBS software sends an INT14 AX=xx
instruction to turn on encryption.

    Tim
-- 
    Internet: pozar@kumr.lns.com     FidoNet: Tim Pozar @ 1:125/555
Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA
             POTS: +1 415 788 2022  Radio: KC6GNJ / KAE6247

What about a streams module that does encryption?  Of course, it'd
require people to run a real OS instead of dos/system...

--
J. Eric Townsend jet@nas.nasa.gov 415.604.4311
NASA Ames Numerical Aerodynamic Simulation      |    play: jet@well.sf.ca.us
Parallel Systems Support, CM-5 POC              |      '92 R100R / DoD# 0378
PGP2.1 public key available upon request or finger jet@simeon.nas.nasa.gov

Excerpts from internet.cypherpunks: 7-Apr-93 Real-time BBS Encryption??
by Eric Hughes@soda.berkele 
> For PC's, replacing the terminal software is really the best way.
> There is no effective abstraction of serial port hardware in the PC
> world.  The int 0x14 driver in the BIOS was rampantly defective, and
> MSDOS does not provide a standard interface.
>  
> As a result, almost all comm software on PC's talks to the serial port
> directly.  Now in MS Windows, there is abstraction for ther serial
> ports, but I don't know how easy it is to insert a device layer.

Actually, there is a rather old (for the PC) abstraction called FOSSIL
(Fido Opus Seadog Serial Interface Layer ... or so).  It is essentially
an extention/replacement for the BIOS int 0x14 driver.  It is certainly
possible to further extend this for encryption by adding some functions
to the interface.  The two FOSSILs I know of are X00 and BNU - They can
be found in oak.oakland.edu:/pub/msdos/fossil
-- 
David Sward    sward+@cmu.edu