
SerialRedirector (c)opyright 1998-1999, Technical Innovations


Abstract

SerialRedirector is a Windows program which accepts network
connections and exchanges data between them and serial ports on the
host PC.  It offers the ability to set baud rates and line discipline
for ports, implements user id/password based security, and provides
(optional) basic encryption for data as it passes over the network. It
is written in Visual C++ V5, using multithreaded MFC and is released
under the GNU General Public License.  Runs on 95/NT4 and should work
OK on 98/2000.



SerialRedirector Features

- Listens for TCP/IP connections from any other system on a network
- and provides a network interface to one or more serial ports on the
- host PC.  Runs on Windows 95 and NT4.  Although untested, it should
- run on Windows 98 and 2000. When its finished, the Open Source
- release for Linux will be available as well.  Implements several
- layers of security to safeguard the devices it communicates with and
- the data exchanged with them.  The connection protocol used to
- connect to SerialRedirector is simple, facilitating its use by
- anyone.  Minimizes to a task bar icon, which when doubleclicked,
- shows a dialog containing statistics relating to services in use,
- users logged in and throughput/queue length.  Configured using
- simple text files rather than labyrinthine registry entries, easing
- remote administration.

Licensing - SerialRedirector is released with source code under the
GNU General License, version 2.

Support - We provide full support of SerialRedirector for our
Observatory products customers.  Although we provide no guarantees for
other users, we will try to help as we can.  All updates/bug fixes to
SerialRedirector will be released under Open Source.


Key Concepts:

Services - A Service is an arbitrary name given to the serial port to
which a device is attached that is going to be offered to the network
via SerialRedirector.  For example, if a modem were connected to COM2,
you might refer to the "modem" service on COM2.  - Only serial ports
explicitly offered as services via entries in the configuration file
are opened by SerialRedirector.  - Several services can be
concurrently offered for a single port (to implement different baud
rates/line discipline, etc..), but only one of them can be online at
any time.  There is no inherent limit on the number of services
offered.  - Each service specifies its serial port, baud rate and line
discipline, connect options and optional encrypt key.  - The number of
concurrently connected services is limited only by the available
resources of the host computer.

Users - SerialRedirector employs a list of user Ids and passwords to
provide access to services.  Each user ID and password have an
associated list of services to which they can connect.  - A given user
ID and password may be concurrently connected to any number of
services.  - Only one user can connect to a given service at any time.

Encryption - Service Key - A (hopefully) random alphanumeric,
case-sensitive sequence of at least 8 characters, associated with a
service, and used as a basis for encrypting the data passing to and
from it over the network.  This sequence is assigned by the user, and
is known to both the client and SerialRedirector- but is never
transmitted by either.  - Keyphrase - A sequence of random characters
of random length between 16 and 64 bytes.  It is generated by
SerialRedirector and sent to the client program during the login
process.  - Effective Key - The resulting key formed by interleaving
characters from the Service Key and Keyphrase.  With the Keyphrase
used first, the Effective Key is formed by alternately appending a
character from the Keyphrase and Service Key until all characters from
each are used at least once.  If either key's length is reached before
the other, the algorithm must rollover its index to continue reading
characters from the beginning of the key.  The rollover can happen as
many times as required for either key.  Due to the random nature of
the length of the Keyphrase, this causes the Effective Key to be
different in length and value each time a client connects to a
service.

Configuring

	There are two configuration files for SerialRedirector;
	config.conf and users.conf .  Both are located in the same
	directory as the SerialRedirector executable.  Neither file is
	encrypted.  System security should be enforced to prevent
	unauthorized access to these files, as only the system
	administrator should see or update them.

Config.conf contains all the parameters needed for SerialRedirector to
offer services, and is read only once when SerialRedirector is
started.

Users.conf contains the list of the user Ids which are allowed to
connect to services.  Associated with each user id is their password
and list of allowed services.  This file is read whenever a user
attempts to log in, so updates are effective immediately. Telnet would
be a good way to remotely administer SerialRedirector if 95/NT offered
it- however ftp offers a clumsy but workable alternative.  If you use
Windows networking to administer software, you deserve your fate... ;)

There are detailed comments in both files which document their
respective contents.


Using SerialRedirector

	If encryption is not supplied for a service, Telnet can
	connect to it.  The login procedure is much the same as a
	Telnet login to most other types of TCP/IP servers.  Once
	Telnet connects, the user could type the following- needing
	only a carriage return between lines.  Linefeeds are ignored.

service <servicename> -- note this line MUST preceed the other 2 user
<username> pass <password>

The obvious substitutions should be made with the appropriate values.
The server will not echo back keystrokes and will respond with Success
or Failure only after all three entries are submitted.  The login can
fail because the service is already in use, the user ID/password are
incorrect, or the requested service doesn't exist or isn't allowed for
the user.  The only specific failure code results from the service
already in use case- the others are identified by a generic code.
SerialRedirector allows 10 seconds for each line to be completed or
the connection is dropped.  Once sucessfully logged in, everything you
type is transmitted thru the serial port, everything received by the
port is sent back to your Telnet session.  The baud rate and other
parameters applied to the port are given by the service entry in the
configuration file.  The <servicename> supplied above selects the
service to which the user is attempting to login.  The user's
ID/password entry must allow access to the service before the login
can succeed.  There is no logout procedure, simply breaking the
connection is sufficient.  Once connected, there are no inactivity
timeouts or connect time quotas.

	If encryption is supplied, Telnet won't work (because it can't
	encrypt/decrypt the datastream), but the login procedure
	remains similar.  Once the 'service' line is submitted, the
	client and server begin using the service's keys as supplied
	to them by the user.  Next, the SerialRedirector generates a
	random Keyphrase.  This is encrypted and transmitted to the
	client and both use the new key to modify the original Service
	Key, forming the Effective Key which is used in all subsequent
	communications.  If the client and SerialRedirector end up
	with matching Effective Keys, the login can proceed
	successfully with the user and password lines.  If the
	Effective Keys don't match, the login cannot complete (because
	SerialRedirector will be receiving garbage).  SerialRedirector
	drops all failed login attempts immediately after transmitting
	the login failure message.  Please see the example client code
	for details on implementing encryption.

	The encryption model is simplistic and should not be expected
	to resist competent crack attempts, however it should prove
	effective against general network surveillance by
	programs/people attempting to extract user Ids, passwords or
	other possibly sensitive information.  It should also resist
	packet playback attempts to a significant degree.  Finally, it
	adds an additional measure of security because login attempts
	cannot succeed until the matching Effective Key is used by the
	client software.

	The design accepts the possibility that an attacker knows the
	algorithm, but not the Service Key, which is known only to the
	Serial Redirect server and client software and is never
	transmitted by either. The robustness of the algorithm depends
	on the obscurity of the final Effective Key.  Long, random,
	non-repeating Service Keys are preferred.  During the
	Effective Key calculation phase, the server generates the
	random Keyphrase and transmits it to the client.  The
	Keyphrase data is encrypted in transit by the original Service
	Key, so it is never plainly visible and therefore is nominally
	secure.  The random Keyphrase is neither stored nor re-used,
	so it cannot be used in pattern attacks against Service Keys
	in other sessions.


Current Issues

	At this time, SerialRedirector's throughput leaves something
	to be desired.  I designed it to be able to buffer large
	quantities of data in either direction- allowing very
	different transmission rates on the serial and network sides.
	Half-duplex communication reveals some shortcomngs in this
	approach, as the algorithms pause to allow blocks of data to
	be filled in both directions before passing them on to their
	destination.  I have not exhaustively tested the programs
	performance over a variety of applications, so it is possible
	the buffering logic is a greater liability than it is a
	virtue.

	Further, there are no provisions for logging, monitoring or
	dropping incoming connections- these would be useful
	enhancements.

	I'm not terribly happy with the encryption model- I took a
	very simplistic view of the topic and I think a more robust
	algorithm might be useful.  However, due to the US Gov'ts
	position regarding strong encryption, it is possible that use
	of one could have unfortunate consequences.  My algorithm
	encrypts each character sent over the network by XORing it
	with 2 consecutive bytes from the Effective Key.  The index
	into the Effective Key is incremented by one after the 2 XORs,
	so each character of the Effective Key is used twice for two
	adjacent data characters.  The double XOR prevents ASCII 0
	characters in the datastream from directly revealing the
	Effective Key (although long enough sequences of identical
	bytes will tend to reveal patterns in it), and using each
	Effective Key char twice in consecutive data chars increases
	the obfuscation of the data (at least I think so- but I'm
	obviously no cryptologist).

	I am also dubious about the login timing constraints (10
	seconds to complete each line or SerialRedirector drops the
	connection).  It is intended limit the effectiveness of DOS
	attacks and is also a consequence of my implementation of the
	thread in charge of listening for connections.  I 'm not
	highly skilled in designing network servers (but Windows
	doesn't make it a whole lot easier either), so it's likely the
	implementation could be much improved.


Interfacing to SerialRedirector

	A sample application is included with the distribution,
	written in VB 5, which supports both encrypted and unencrypted
	connections.  It is cobbled together from various other
	programs, but it works well enough.  Its principal advantage
	is it shows how to form the Effective Key from the Service Key
	and Keyphrase- in addition to the requisite datastream
	encryption/decryption functions.  Refer to the tcpConnect
	function in TCPIP.BAS- and please pardon the particularly
	hideous coding I find to be required for anything but the most
	trivial use of the Windows Socket ActiveX control.

	Beyond the timing constraints imposed on the login process,
	using SerialRedirector is a simple exercise in TCP/IP sockets
	programming- there is a large body of documentation on that
	topic, so I won't go into it here.


Regards,

Greg Menke 4/20/99 domepage@erols.com



