[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
advantages of RS-232 based crypto device
- To: [email protected]
- Subject: advantages of RS-232 based crypto device
- From: [email protected] (Yanek Martinson)
- Date: Wed, 25 Nov 92 22:29:06 EDT
- Cc: rmsdell!ym (Yanek at Work)
A number of people responded, both privately and publicly to my RS-232
dongle idea. Several offered help with the hardware/schematics
design.
Some thought that PCMCIA cards would be better for this.
Theoretically, yes. They could contain more memory and processing
power in a smaller space. There are several problems with PCMCIA.
First, not nearly as many devices have PCMCIA interface as RS232.
Second, you can not make a PCMCIA card yourself, nor can you easily
open it and look what's inside.
My proposed design would consist of only off-the-shelf parts, the
schematic would be published, so anybody could build the device for
himself. I might distribute it in the kit form, which would include
all the parts and the PCboard, and a case. This way, you can test each
component in any way you want, and then put the thing together by
yourself. Even if you got the complete unit from me, you could open it
up, and look inside. You could see if it actually corresponds to the
schematic.
Some people doubted the possibility of its second greatest advantage,
the ability to work with any computer or terminal regardless of
operating system, mail software, comm software, etc. Also it could be
used between an ASCII terminal and a (non-trusted) host.
Here is an example of a design that I think will work with any
software/host/terminal/etc combination. If I am wrong, please let me
know. NOTE: this is not the final design of the device, just an
example.
=====================================================================
Since the device needs to have a processor anyway, it may as well have
a built-in simple line-mode editor that is good enough for composing
mail messages. So to use the device to send mail, you would:
1. Give the mail command to your host (or BBS) using whatever command
or menu selection you normally use to send mail. Then if the mail
program puts you into a mode-based editor like vi, enter insert mode
(press i or a).
2. Push the "encrypt" button on the device (or send a magic sequence
from your terminal).
3. Type your message in a simple BBS style (in case you have not used
a BBS, this is the kind of editor they usually use: You simply type
text. Every line has a number. When you press return, the next line
number appears. At the beginning of a line, you can issue commands for
example with a slash or a dot. commands include things like DONE,
ABORT, DEL LINE, INSERT, etc.)
If you had the text prepared on the local machine, you could simply
transfer the text, and then type the "DONE" command.
All this while, the text is only stored in the memory of the crypto
device, the remote host is still waiting for input. So plaintext never
crosses the line or network.
4. When you are done, the text would be encrypted (you would select a
public key from the keyring, or it could be automatically determined
from preceding text (such as the e-mail address). You would have the
option of signing the text.
The device transfers the encrypted text to the host and becomes
transparent.
You then type the command to tell the host that you are finished typing
the message, and off it goes!
==========================================================================
Now, if you see any reason why the above would not work, please let me
know.
A number of people wondered if the tamper-proof memory for private key
storage was necessary. Some other people wondered if it was in any
way effective (i.e. if someone gets the device, they can just use it to
decrypt/sign stuff; so what if they don't get they actual key out of
it).
I tend to agree. I will have to think some more about this.
It would certainly make the design much simpler (and cheaper, and
consistent with the desire for off-the-shelf parts) if I avoid use of
such exotic hardware.
The private key may be protected from use by un-authorized users by
encrypting it with a key, and requiring it to be entered on a keypad on
the device. Someone suggested that the key must be typed in
periodically (every x minutes).
The only case I could see a problems with this approach is if "they" get
you while you are using the device. For the next x minutes they can
decrypt any old messages they may have stored.
I believe this addresses all the concerns that have been voiced about
this device. If you have any other concerns, questions, or comments,
please let me know.
--
Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek
this address preferred -->> [email protected] <<-- this address preferred
Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood
(305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819