gordon@trsvax (08/14/85)
/* 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 <several character times of line inactivity> <0x1c character> <0x1c character> <0x1c character> <several character times of line inactivity>. 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.
caf@omen.UUCP (Chuck Forsberg WA7KGX) (08/22/85)
In article <53500017@trsvax> gordon@trsvax writes: >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 each dongle delays the serial data several character times, cascading enough of the buggers will make a good serial memory! At 1200 bps, 500 dongles with 4 characters of storage each (2000 total) would cause a delay greater than 16 seonds. This would make the serial port virtually useless for communications. And, just think of how much grief a nearby lightning strike (such as the one that blew out most of the RS232 chips at a campus in Hawaii) will cause. A better solution would be for ADAPSO to develop a version of the 8088 with a serial number burned in to it. The software would then be installed for that particular CPU serial number, with a certain number of invocations allowed on other machines for emergencies. Serialized CPU's might also be useful in tracking stolen equipment. -- Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf CIS:70715,131 Omen Technology Inc 17505-V NW Sauvie Island Road Portland OR 97231 Voice: 503-621-3406 Modem: 503-621-3746 (Hit CR's for speed detect) Home of Professional-YAM, the most powerful COMM program for the IBM PC
slerner@sesame.UUCP (Simcha-Yitzchak Lerner) (08/23/85)
[eat this!]
Gordon Burditt posted a long article regarding communications transparency
of keys, 50' stacks of keys etc...
For RS-232 ports (there are other transport protocols for other types
of ports) there are 2 different standards. The primary std. is to
communicate over status lines. This method remain fully transparent
at all times, even while validating a program. The second method
is a fallback for machines that either do not have status lines on
their RS-232 or can not control them (eg:protected environment). This
method uses a long (9 character) escape sequence, combined with a
guard period of no transmission. This system is transparent as
long as a validation session is not in progress. Most of the points
made by Gordon where correct, you would have thought that he had
read the specs!
In regards to physical clumsiness: Unlike the UK dongle, the ADAPSO
key does not daisychain. Rather, they all plug into a central keyring
which handles all communication/traffic managment for the system. Keys
(1st generation) will not be much bigger that an 8088 standing on edge
(sans pins). You can plug a lot of these into a keyring the size of a
modem.
Finally, in regards to the possibility of something like each
UN*X utility needing a seperate key: It is possible to have a
company come out with a smart key that services all of their
products. (This is done by it recognizing multiple key IDs.)
Parts of this key could be turned on via a cheap one-shot key.
So a company with a lot of products that are often bundeled
could have them all authorize off of one key. Their advantage,
with a single key they can afford to put in a lot of power for
a lot of protection - they couldn't afford to do this for every
product. The cheap one-shots wouldn't need to much to them.
The consumer benifits - only one slot is used, avoiding the need
to buy expansion units for their keyring, increased portability
(you only have to move one key when your system dies).
Regretfully, anything above useing a scouts honor promise to
protect your software will have to involve the manufacturer
if it dies. One of the many advantages of a hardware key over
a disk is that it is a lot more sturdy. (When was the last
time you had to replace a worn out ROM chip?) Hopefuly, some
manufacturers will diferentiate themselves by offering some
type of 24-hour 7-day/week responce to dead keys. [A few
cos are even talking of supplying a BACKUP key w/ their
product. Assuming that you didn't give it away to a friend,
you would be able to recover with the backup until the replacement
came...
--------------------------
BTW to flamers:
While I work for Lotus, I have created, developed, and nurtured this
project on my own time for my own reasons. I am NOT a paid puppet
spouting Lotus' official line - most Loti don't even know newsnet
exists, as my link is not via a Lotus machine. If you truely
feel you must flame me, why don't you send it to me as mail, so
we don't bother everyone on the net? Who knows, I may have a
flame thrower too, somewhere in this drawer?? :-)
--
Opinions expressed are public domain, and do not belong to Lotus
Development Corp.
----------------------------------------------------------------
Simcha-Yitzchak Lerner
{genrad|ihnp4|ima}!wjh12!talcott!sesame!slerner
{cbosgd|harvard}!talcott!sesame!slerner
slerner%sesame@harvard.ARPA greenber@timeinc.UUCP (Ross M. Greenberg) (08/24/85)
In article <225@omen.UUCP> @.UUCP (Chuck Forsberg WA7KGX) writes: >In article <53500017@trsvax> gordon@trsvax writes: > >If each dongle delays the serial data several character times, cascading >enough of the buggers will make a good serial memory! At 1200 bps, 500 >dongles with 4 characters of storage each (2000 total) would cause a >delay greater than 16 seonds. This would make the serial port virtually >useless for communications. > But think what a nifty volatile memory device it would make! :-) Memory? I don' need no stinkin' memory! I got cascaded dongles! -- ------------------------------------------------------------------ Ross M. Greenberg @ Time Inc, New York --------->{vax135 | ihnp4}!timeinc!greenber<--------- I highly doubt that Time Inc. would make me their spokesperson. --- "You must never run from something immortal. It attracts their attention." -- The Last Unicorn
slerner@sesame.UUCP (Simcha-Yitzchak Lerner) (08/25/85)
> > If each dongle delays the serial data several character times, cascading > enough of the buggers will make a good serial memory! At 1200 bps, 500 > dongles with 4 characters of storage each (2000 total) would cause a > delay greater than 16 seonds. This would make the serial port virtually > useless for communications. > > A better solution would be for ADAPSO to develop a version of the 8088 > with a serial number burned in to it. The software would then be installed > for that particular CPU serial number, with a certain number of invocations > allowed on other machines for emergencies. > > Serialized CPU's might also be useful in tracking stolen equipment. > Please read previous postings on the ADAPSO key/keyring system. Unlike the UK dongles, the ADAPSO keyring system does NOT daisy chain - ONE kering does all communications for MANY keys, therefore propogation delays are minimal. Serial numbers in CPUs will not be acceptable for many reasons, starting with what to do if your machine dies up to and including what to do if you want to take some software home for non-simultaneous use?? -- Opinions expressed are public domain, and do not belong to Lotus Development Corp. ---------------------------------------------------------------- Simcha-Yitzchak Lerner {genrad|ihnp4|ima}!wjh12!talcott!sesame!slerner {cbosgd|harvard}!talcott!sesame!slerner slerner%sesame@harvard.ARPA