Re: More comments on dongles

[karn@qualcomm.com (Phil Karn)]

>The way I envision it, the host must NOT have the ability to turn it on
>or off or do any of the other things you mentioned.  The assumption is
>that you DON't trust the host.

If you don't trust the host, then why are you running your plaintext
through it?

As I said earlier, my decision whether to trust a particular machine
depends heavily on how much I would lose if that trust were abrogated.
I might be willing to take the chance that this particular borrowed or
public PC has been hacked if the worst that can happen is that the
only slightly sensitive plaintext I'm working on at the moment is
compromised. Heck, I might even be signing or decrypting totally
public information, just to help raise the amount of encrypted traffic
on the net. In this case I might not care at all if my plaintext is
secretly recorded or sent somewhere.

But I would probably NOT be willing to trust the same PC with my
secret key, because it would compromise EVERYTHING I have ever
protected (or will protect) with that secret key. Including THE most
sensitive stuff I might have, the plaintext to which I might entrust
only to a RAM disk on my own home PC. Do you understand the
distinction here?

>So if the host does not even need to know the dongle exists, it is
>automatically independent of what type of computer, operating system,
>communications program or terminal you are using.

I seriously doubt this will be practical, even with constant
interaction with the dongle's keyboard. Most palmtop keyboards are a
real pain to use, so I would definitely prefer to limit my use of it
to truly sensitive things, like typing in my pass phrase to decrypt my
RSA secret key, or perhaps hitting a key to re-enable the device after
every N secret key operation requests from the host, or to restart a
timer that would otherwise exit the program and clear RAM after a
timeout in the event the device is lost or stolen.

>Again, you are trusting the host.  What if the decryption program on 
>the host has been modified to quietly write the plaintext to a hidden 
>file.  

As I said earlier, your "fully-functional dongle" fails to prevent
this attack. If it sits on a serial port between your possibly hacked PC
and the outside world, then it clearly must pass decrypted plaintext
to the PC where it could still be quietly written to disk.

>Once the host decrypts the file (at a high speed, as you say), you want
>to view the file, right?  That means the plaintext is transmitted from
>the host to you.  Anywhere in the link (which could be a simple RS-232
>connection, or a chain of network links, modem connections, etc.,
>someone may be watching.  With my design, the decryption takes place at
>the very last step, just before showing up on your screen.

Eh? The model I have is a local PC, possibly hacked, with a serial
port connected to my personal dongle sitting right beside it.
Obviously it would not do to have an insecure link between the PC and
the dongle (unless you had encryption on that link, as I suggested in
the case of using a remote machine in place of the dongle.) It should
be fairly hard to inject your own traffic on my 1-foot RS-232 link,
especially if I provide my own cable.

>I have thought of that too.  I would need one with two serial ports
>though.  If you know of a good, cheap (can something have these two
>properties simultaneously? :-) notebook computer with (option of?) two
>serial ports, please let me know.

The "basic dongle" would only need one RS-232 port, and it would not
have to be fast. This is a definite advantage.

>That is just one of the reasons.  The others are convenience, lack of
>trust in the host or the network, use of a terminal (which can't run any
				   ^^^^^^^^^^^^^^^^^
This is the one valid reason I can see for your approach. But dumb terminals
are getting pretty rare these days, at least in the places I hang out.

Phil