Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: Notesfiles $Revision: 1.7.0.8 $; site trsvax Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!inuxc!pur-ee!uiucdcs!convex!trsvax!gordon From: gordon@trsvax Newsgroups: net.micro.pc Subject: More dongles Message-ID: <53500017@trsvax> Date: Tue, 13-Aug-85 22:08:00 EDT Article-I.D.: trsvax.53500017 Posted: Tue Aug 13 22:08:00 1985 Date-Received: Sat, 24-Aug-85 02:46:56 EDT Lines: 129 Nf-ID: #N:trsvax:53500017:000:7729 Nf-From: trsvax!gordon Aug 13 21:08:00 1985 /* Written 6:21 pm Aug 1, 1985 by sesame.UU!slerner in trsvax:net.micro.pc */ /* ---------- "Re: Re: software protection - dongl" ---------- */ ... Under the ADAPSO key/keyring system, the software is not copy protected in any fashion. Therefore it can be installed on a network server (1 copy) and run from any compatible system on the network, **as long as the system running the software has a key that matches the software.** This works without any problem because the ADAPSO device is _not_ a copy protection device but an execution authorization device. ... /* End of text from trsvax:net.micro.pc */ I don't have a copy of the ADAPSO standard, but I have heard various comments about dongles being transparent to other uses of the serial channel except when the dongle activation code gets sent out. Does the standard consider making the dongle as close as you can get to truly transparent, and make it easier to deal with multiple dongles? The requirements, as I see them: 1. There is a documented lead-in sequence that begins the activation sequence to all dongles. The user is told this sequence, so the serial channel can be used for something else without interference if the user avoids sending this sequence. Merely avoiding one particular character isn't good enough - that is too much of a pain to avoid. I suggest making the sequence<0x1c character> <0x1c character> <0x1c character> . If this sounds similar to the escape to command mode on the Hayes modem, you're right. The idea is I want to be able to send blocks of raw binary data without activating the dongle. It is reasonable to assume I can arrange to send a block without pauses in the middle of it. Yes, this is going to give the hackers a starting place at cracking the dongle. But it doesn't have to be much help if the rest of the sequence is complex enough. 2. The rest of the activation sequence for the dongle is secret and different for each type of dongle. If the activation sequence is correctly sent, NO characters are sent out the remote end. If any character, including the last one of a couple hundred, is wrong, the entire sequence (with the proper timing for the first part of the lead-in sequence) is sent out the remote end, to pass on to the next dongle or whatever is connected at the end. 3. After the dongle is activated, conversation between the dongle and the program is secret and unspecified. The dongle can be acting as a decryption device. Both the program and the dongle agree on when the conversation is ended, and nothing goes out the remote end while the conversation is going on. The conversation with the dongle should avoid including the universal activation sequence for a dongle that might be connected between the activated dongle and the computer. This portion of dongle operation provides most of the security. The program should attempt to avoid making the conversation fixed: some random number should be thrown into the conversation to make it vary the dongle output in a way that the program can check, to avoid someone with a RS-232 data monitor creating a fixed-script "dongle emulator". The point of these requirements (and the one that requires buffering sequences that almost match is probably going to cost a little in dongle complexity) is that I can use ONE serial port, and connect all of the "transparent" dongles (which I assume will physically look like a "null modem": connectors on both ends, about 2 inches long, with a cord running to a transformer/power supply) into one big chain of dongles maybe about 50 feet long, and connect it to the port. Each dongle either accepts the request or passes it on to the next one. Mechanical support for that many dongles may be a problem, but all of the programs requiring the dongles should still work, regardless of which order the dongles are connected. If transporting programs from one cpu to another isn't a normal mode of operation, but is used mostly for failure recovery, then this virtually eliminates the dongle-switching problem. The dongles should be designed so it is possible to cascade a reasonable number of them on one serial channel. If the standard really catches on, and most software packages use it, then I guess a "reasonable" limit is between 500 and 5,000 dongles on one serial channel. Dongles should NOT try to derive power from the RS-232 signals: there won't be enough power for lots of dongles. With the current paranoia on the part of software vendors, and lots of unbundling, I fully expect that every UN*X * command will need its own unique dongle, and ls, ls -s, ls -i, ls -l, ls -si, ls -il, ls -sl, and ls -sil will require 8 different ones. If my computer breaks down, I grab my backup disks/tapes/whatever, my tower of dongles, the complex network of power strips to plug the dongles into, and try to transport this unwieldy mess to my associate's computer system, since I have a reciprocal agreement to share computers in case of disaster. Then I restore my data onto his system along with his, plug my tower of dongles onto the end of his tower of dongles, and I'm up and running. This is a lot better than copy-protected software, since there is a good chance the failure took out the copy-proof disk if it was being used at the time. I still maintain that anyone who is going to put significant effort or money into use of a program is an idiot if they buy copy-protected software without a darned good assurance they can get a replacement copy at all, on reasonable terms, and QUICKLY (how many companies can get you a replacement copy in 24 hours if your disk fails just before a tax deadline, at 1am Sunday morning? Even if you're willing to pay Federal Express exhorbitant fees to deliver it? I don't consider even that to be very good service on a program your business depends on). "Significant effort or money" is more likely to be your investment in keying in your accounting data than the purchase price of the software. I exclude games and useless software. Anything your business depends upon to still function is very significant. If you can't get a program that provides that kind of service, and I don't think any company currently selling software does, and it isn't economical to buy a couple dozen backup copies, even at full purchase price, then you shouldn't be using that package at all. Even if you have to go back to chisel and stone tablet accounting records (if it wasn't economical to buy backup copies at full price, it's either very expensive software or it doesn't save you much money using it), it's better than risking paralysis of your business. Dongles have the promise of being much more reliable than floppy disks, but you should still worry about having to get a replacement. (Imagine a lightning strike on a phone line takes out your modem, 280 out of 300 dongles, and the serial port on your computer. Or one of your employees takes a dongle home for the weekend (legal, remember?) and loses it. In this last case, expect to pay full price, but will you be able to get a replacement fast?) At least you can still run if anything but the dongle fails, assuming you have arrangements for getting a loaner system, or have more than one system of the same kind. * UN*X is a tr*de m*rk of some p*ece of th* ph*ne c*mp*ny, and nob*dy c*n f*gure o*t wh*t it's c*lled n*w. Gordon Burditt ...!convex!ctvax!trsvax!sneaky!gordon ...!ihnp4!sys1!sneaky!gordon The opinions expressed are mine alone, and have no necessary resemblance to those of my company, my hamster, or your dead cat.