From: Russell Nelson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Is a serial cable as good as thin air?
>Arnold G. Reinhold writes:
> > I am uncomfortable with the tone of this thread. There is nowhere near
> > enough information provided in Mr. Georgoudis' posting to conclude that
> > hisbank's existing floppy disk transfer scheme is secure, much less render
> > an opinion on the impact of a serial connection.
Russell Nelson responds:
>He didn't ask if it was secure. He only wanted to know if a serial
>connection could be made as secure as a floppy disk transfer. I
>contend that an xmodem transfer of the file is as secure as a floppy
>disk transfer. The truly paranoid would insert a PIC chip which
>enforces that only the xmodem protocol could transit the wire, and
>then in only one direction.
>Sure, the floppy disk transfer could be insecure, but as you say, he
>neither gave us enough information, nor asked if we felt it was
>secure.
I think we need to revisit the original problem: can a serial-wire
transfer protocol be implemented that protects the bank's computer
from providing unlimited access. The simple answer is 'yes' - but it
will require some modifications to the bank's software. First, the
serial port must be isolated from existing drivers so that you can
ensure that the port cannot be hijacked through whatever means.
Then, the new driver must provide very specific services with
appropriate protocol added to ensure that the data coming in the port
is real -- you guys with more crypto experience can devise that
scheme probably better than I can. Once you have written the driver
with appropriate authentication and security protocols, and limited
its range of action to processing only one type of transaction
(updates from the remote terminal), the ability of an intruder to
access any other data on the system is removed.
Of course the connection must be 2-way because the protocol must
provide for feedback to ask for resend of bad blocks, and commands to
send the data must be implemented. But the driver can clearly be
made to receive data only - never to send anything except commands
and acknowledgments. Xmodem would work (Ymodem and Zmodem would
probably be a bit better simply because they are faster), but it
still would need a protocol of some sort added to specify what data
to transfer, and perhaps to update keys or purge old data, etc.
Were I coding the system, I think I would implement a custom protocol
for everything and avoid something like Xmodem simply because I don't
like the flow-control baggage you get with them. Such a package is
relatively simple to implement, and can be made as robust as your
requirements demand.
Carl Carter - Software Eng Sansearch, Inc.
[EMAIL PROTECTED] 10225 Willow Creek Rd
voice........(619) 635-5300 San Diego, CA 92131
fax............(619) 635-5299
