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
I think we are using different terminologies, maybe even different paradigms of how e-mail and other internet functions are accessed by people. In my terminology, "host" is the remote multiuser computer that is on the internet, and provides access to users via dial-up modems, local RS-232 terminals, and PC-s running terminal emulation programs. The host could also be a BBS system (as in the case of FidoNet) which provides mail forwarding for you. It could be an on-line service such as GENIE or Compu$erve. Local equipment is the terminal, or Pc or Mac or whatever, that you use to connect to the host. It could also be the laptop that you connect to a cellular modem and connect to the host while mobile. You could always use the same local equipment. Or you may use different types at different times (a terminal at work, a PC connected through a modem from home, a firend's Mac, a borrowed laptop using a cellular modem, etc). The connection could be direct, as in the case of a terminal or a direct dial-up by modem. Or the connection could go through multiple channels. For example you could dial up a TYMNET POP, and then connect to your host. Or, you could call up a terminal server, log in to a guest account, and then telnet or rlogin to your host. In this scheme, the dongle sits right between the local equipment and the connection.
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?
In view of what I have said above, I am NOT running the plaintext through the host. I am running it through local equipment, which I may or may not trust. The host (being the multiuser system, administered by someone else) is always less trustworthy. It is directly on the network/ It could be immediately transmitting everything you type to NSA for all you know.
... if the worst that can happen is that the only slightly sensitive plaintext I'm working on at the moment is compromised. ... But I would probably NOT be willing to trust the same PC with my secret key, because it would compromise EVERYTHING I have ever ... Do you understand the distinction here?
Yes, I certainly do. That is the reason for having a portable trusted device in the first place. But, in this sense our two approaches (my smart dongle that does all the crypto functions, and yours that only stores the private key) are absolutely equivalent. None of the two exposes the private key in any way.
So if the host does not even need to know the dongle exists, it is automatically independent of what type of computer, operating system,
I seriously doubt this will be practical, even with constant interaction with the dongle's keyboard.
See my next post "STORY: scenario of use of Crypto-Dongle" for my vision on how this would work. Then, if you see any problems with it, or suggestions for improvement, please let me know, so I can improve 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
That is the kind of things I intend the keypad to be used for.
Most palmtop keyboards are a real pain to use ...
The dongle will have a numeric keypad, somewhat like the touch-tone phone, with letters on the number keys, and a couple of extra keys such as * and # for functions.
Again, you are trusting the host. What if the decryption program on
As I said earlier, your "fully-functional dongle" fails to prevent
This misunderstanding is due to our differing use of the word "host". When you said the host would send the rsa-encrypted key to the dongle, receive the decrypted session key, and then decrypt the file, I understood you as meaning that the remote multiuser machine is doing all this. Now I see that you meant for the local equipment to perform the decryption. The problem with this is that you are depending on every piece of local equioment to have a copy of the decryption program, and every version of that program compatible with your dongle's commands structure and key format. Or you'd have to carry a several disks with you, with a version of your software for every platform you could encounter.
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
Eh? The model I have is a local PC, possibly hacked, with a serial port connected to my personal dongle sitting right beside it.
In this case, you would have to save the encrypted message into a file on the host, download it to your local machine, and then decrypt it using the above approach. This would be some amount of hassle, when compared to just using the mail reader software on the host. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek@novavax.nova.edu <<-- 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
participants (2)
-
karn＠qualcomm.com -
yanek＠novavax.nova.edu