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.