srb%mycroft@GSWD-VMS.ARPA.UUCP (01/16/87)
>An interesting authentication scheme uses a special calculator >issued to each user. The calculator has a crypto chip and is >keyed before being given to the user. To determine whether a >user is valid, the system presents a challenge in the form of >an integer (probably 5-6 digits long) which the user keys into >his calculator. The calculator applies the encryption algorithm >and key to the input and produces an integer output which the user >then keys into his terminal/PC. >... Authentication is normally based on "something you know" or "something you have". A small weakness of the scheme as described is that you could lose the calculator and then someone else would have it... I'd suggest that the calculator itself have a "password", under the control of its owner, which enters into the cryptographic algorithm. (Since the calculator is not networked, monitoring of the password entry is unlikely.) At this point, something you know AND something you have are necessary to gain entry.
ms6b#@ANDREW.CMU.EDU.UUCP (01/17/87)
The January issue of Data Communications refers to some work being done by NBS to help the Treasury department upgrade its electronic fund transfer systems along the lines you describe. Encryption will require both a physical key and a password.
karn@FLASH.BELLCORE.COM.UUCP (01/17/87)
I have already implemented a crude scheme which works exactly in this way. I run a UNIX system which is available over amateur packet radio. From time to time I will access it from a friend's station over the air. Needless to say I don't want to blast my root password or even my personal password over the air, so I implemented a challenge/response system using DES. You first log in using a special password-less ID. The system then prompts you for your real login name. Then it sends you the UNIX time-of-day, expressed as a 64-bit hexadecimal number. You encrypt this number and type back the ciphertext. To do the computation, I wrote a program called "descalc" for the PC (though portable) which allows you to set a key, enter plaintext and read back the cipher text, enter cipher text and read back the plaintext, etc. (I'm still working on the command that takes the cipher and plain text and reads back the key. :-) The system keeps its list of keys in plaintext form in a read-protected file; this is probably the a weak spot in the system (next to the possibility of somebody "taking over" the connection after I've authenticated it). If somebody can show me how to do this scheme without keeping cleartext passwords in the system and is reasonably fast, I'm all ears. However, I think it's just a stopgap until I switch to full time TCP/IP operation on the air and implement authentication on every IP datagram. I will probably post this stuff on USENET shortly. The DES was derived from a version already posted there, and I modified it for improved speed and modularity. Phil