One of our devices is controlled from a PC using the serial
interface. One of our customers has security concerns as the
protocol used, though proprietary, is not encrypted.

As adding encryption to our - dated - device is not a viable
option, I have gotten the task to find out if we can find
some third party solution that plugs into the serial stream
and encrypts/decrypts the data stream with a corresponding
library to do the same on the PC.

Something along those lines:

+--------+ +--------------------------+
| device +-- rs232 open ---+ third party en/decryptor |
+--------+ +-----------+--------------+
|
|
rs232 encrypted
|
|
|
+-------------+-------+-----+-----------+
| | | en/decryption |
| PC | | library |
| | +-----------------+
| | |
| | original app |
| | |
+-------------+-------------------------+

Does anyone know of a product that offers this? I have
found a number of "port servers" with rs-232 on one side
and TCP/IP on the other side but we need rs-232 on both
sides.

I would appreciate any pointers.

Cheers
Urs

--
"Change is inevitable, except from a vending machine."
-- Urs Beeli, <usenet@CONCAT_MY_FIRST_AND_LAST_NAME.ch>

Urs Beeli wrote:
A lot depends on the strength of encryption required. It sounds as
if not much is needed, so xor'ing with the output of pseudo-random
generator should do. All you have to do is arrange to sync with
the generator. The result should protect against idle
eavesdropping, but not against determined attack. You could build
the unit out of a PIC.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

Who is the anticipated attacker? Your scenario still has data in the
clear between device and encryptor box. Anyone could insert a wedge
here and get cleartext.

On 22 Mar 2006 07:52:31 -0800 larwe wrote:
I realise that. Personally I do not see that we even need such a device.
However, the customer cannot be talked out of it and the suits in management
now have a new buzzword, so here I am looking for encryption solutions :-)

Cheers
/urs

--
"Change is inevitable, except from a vending machine."
-- Urs Beeli, <usenet@CONCAT_MY_FIRST_AND_LAST_NAME.ch>

On Wed, 22 Mar 2006 09:57:56 -0500 CBFalconer wrote:
That would certainly be a technically viable solution. However, I don't
think that for the few cases where a customer insists on enrcypted
communication we will build a solution ourselves.

I was hoping that someone could point me to a ready-to-buy-third-party-
product. I have found some on the web but thought some of you here may have
experience with such products and could recommend (or disrecommend :-)
certain products.

In any case, thanks for your answer.

Cheers
/urs
--
"Change is inevitable, except from a vending machine."
-- Urs Beeli, <usenet@CONCAT_MY_FIRST_AND_LAST_NAME.ch>

Urs Beeli wrote:



They exist. http://www.simrex.com/site/products/special.htm for
instance.

There are also Ethernet to serial gateways that have 3DES support.
Google for that and you'll find products such as
<http://www.networktechinc.com/srvsw-term-ssh.html>. Of course it means
rewiring the main cable run for Ethernet instead of RS232.

Expect to spend a LOT. For simple Mickey Mouse protection, which is all
you seem to need, an 8-bit micro with two UARTS could implement what
you need in a weekend's programming.

On Wed, 22 Mar 2006 16:13:34 +0000 (UTC), Urs Beeli <usenet@CONCAT_MY_FIRST_AND_LAST_NAME.ch> wrote:

How about using a USB to Serial cable. Using virtual COM port drivers at the PC end would make the
difficulty of interception at the PC similar to any other software based solution, and the far end
would be no less vulnerable than with an encryptor box.
Put a 'super encryptor (TM)' label on it - if the customer doesn't understand that the current
proposed scheme is pointless are they likely to know the difference...?

CBFalconer wrote:
This method you describe is a stream cipher, one example of which is
RC4 which is efficient in software and industrial strength.

The robustness here depends on the quality of the random data.

You do, however, have to be careful never to rekey with the same value
twice, or the two streams can be XORed together to get the XOR of the
plaintexts.

- Tim.

Am Wed, 22 Mar 2006 14:32:47 +0000 (UTC) schrieb Urs Beeli:

Hi Urs,

I would use some kind of Ethernet serial converter and encript the Ethernet
traffic with a common encrypting algorithm, SSL or whatever.
I live in Switzerland too and can recommend something like a
Serial-Server 1xDB25/f,1xRJ45 10Mbps which you will find on www.arp.ch
Not shure if they allow encrypted Telnet but at least it's not so easy to
have access to the plain protocol with a network monitor. This way, more
secure than a serial connection.

PS: Vieli Grüess us Luzern
Lukas

On Wed, 22 Mar 2006 14:32:47 +0000 (UTC), Urs Beeli
<usenet@CONCAT_MY_FIRST_AND_LAST_NAME.ch> wrote:


This mob have them:

http://www.senetas.com/default.cfm?subsection=11
(CypherNET Link Encryptor)
Sold in the US as:
http://www.safenet-inc.com/products/encryptors/link.asp

This will be very expensive, but it will have the appropriate
certifications that will be accepted by govts, banks and three letter
agencies, etc.

Regards,
Allan

Hi Urs,
I can't see why our standard RS-232 protocol converter can't be used.
http://www.pbjtech.com/products/inde...OCOL_CONVERTER

This has RS-232 on one side and RS-232/RS-485 on the other. The second
RS-232 is available off the same DB9 connector. The ARM7 controller has
plenty of grunt for more secure encryption schemes.

We have customers already that require encryption over serial. If you
can specify your requirements we can ship these to you with your
settings preloaded.

*Peter*
www.pbjtech.com
peter@pbjtech.com

Urs Beeli wrote:

On Wed, 22 Mar 2006 15:32:47 +0000, Urs Beeli wrote:

One of the amusing characteristics of RS-232 communication systems is that
since they're bi-directional and byte-oriented, even though the ultimate
bit-rate is not terribly high, by today's standards, the protocol-level
latency demands can be *very* high, compared to internet-oriented packet
protocols. I don't suppose that your device has any particular gotchas,
there?

The other (related) thing to consider is that most of the good encryption
protocols are block based, operating on 64 bits (8 bytes) or more at a
time. If your protocol is byte-based, then you might have to work out
some padding tricks, to make sure that individual bytes get through on
time. This is generally handled by the packetizers in network terminal
servers, but it's something that you'll have to think about, if you want
to roll your own solution.

[snip diagram]
You seem to be prepared to hack up the PC-side application to suit the
solution. If you can't switch to ethernet because you have an installed
run of RS-232 cable, could you go as far as running a PPP link over your
RS-232 cable? That way you could use common off the shelf crypto
libraries/protocols, like SSL or SSH.

I think that a fairly simple mostly off-the-shelf solution could be:

0) Get a Linux/BSD box (quite small ones can be had, like gumstix or one
of the little VIA Mini-ITX PC motherboards). Make at least one
interactive (shell) user account on it.

1) Set it up to boot up with a PPP server running on one COM port and plug
another com port into your device.

2) Put a PPP client on the PC, and have it "dial" the new box over the
main RS-232 link. Verify a working IP connection to the new box.

3) issue the command "ssh new-box cu -n -s 38400 -l /dev/tty00" (seasoned
to taste), and bingo: you've got an encrypted terminal session talking to
the original serial port on your device. Use public keys to avoid the
log-in dialog.

4) use popen("ssh new-box cu -n -s 38400 -l /dev/tty00", "r+") in your
application to give you a file descriptor open to read/write your device.

That should all pretty much "just work", for the cost of an embedded
system with two serial ports and a Linux or BSD installation, with no
actual coding, provided that the time-outs that the ssh session uses to
block up small packets doesn't interfere with your proprietary serial
protocol.

Neat, huh?

--
Andrew

Have you seen the SEL 3021 by Schweitzer Engineering? They make some
pretty good devices for the power electricity market:

http://www.selinc.com/sel-3021.htm

It says US$540 ea.

--
Jim Nagy
Elm Electronics

On Wed, 22 Mar 2006 14:32:47 +0000 (UTC) Urs Beeli wrote:

Thanks for all the many answers. I'll try to answer some of the
suggestions in this one posting instead of following up each of
them.

- terminal server based solutions
this seems to be the most common solutions available, i found
quite a number of those. however, as we have rs232 cable runs
installed I don't see this as an option

- various ideas on how to "roll our own" are noted and would
probably be feasible. however, if we decided to do this
ourselves, we might as well integrate it into our own devices.
as we are tight on resources and our management would prefer
a "buy" solution I don't think we'll continue along this path.
still, thanks for all the ideas

- researching the net and from your suggestions I have put
together the following list of potential devices:

Simrex SimCrypt
http://www.simrex.com/site/products/special.htm

SEQUI EncryptorPak
http://www.sequi.com/SEQUI_Products.htm

DCB SE-660 Serial Data Encrypter
http://www.dcbnet.com/datasheet/se66...OVMTC=standard

Selinc SEL-3021
http://www.selinc.com/sel-3021.htm

CE0058 RS-232/RS-485 PROTOCOL CONVERTER
http://www.pbjtech.com/products/inde...OCOL_CONVERTER

RS-232 to RS-232 adapter
http://www.wrenchman.com/products.htm

Thank you for all your input, we will have a look at these devices and
see which one fits our needs best.

Cheers
/urs
--
"Change is inevitable, except from a vending machine."
-- Urs Beeli, <usenet@CONCAT_MY_FIRST_AND_LAST_NAME.ch>

"Urs Beeli" <usenet@CONCAT_MY_FIRST_AND_LAST_NAME.ch> wrote in message
news:slrne22tl9.7np.usenet@stinky.trash.net...
fibre optic links as those are much more difficult to break into.

Peter