Date: Wed, 25 Sep 1996 16:56:05 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Cc: terry@lambert.org, jhs@FreeBSD.org, current@FreeBSD.org, serious@FreeBSD.org, commercial@FreeBSD.org Subject: Re: Licensing Software Message-ID: <199609252356.QAA07038@phaeton.artisoft.com> In-Reply-To: <199609252250.SAA23107@skynet.ctr.columbia.edu> from "Bill Paul" at Sep 25, 96 06:50:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> No, you have an even worse problem, which is that using an IP address > as a hostid won't work worth a damn, and any company that tries to get > away with this will get laughed out of the business. > > You're assuming (I think) a unique IP address for all machines, which > you're not allowed to do. Some people have machines that aren't attached > to the internet and therefore have fictitious IPs. It may also be that > someone has configured a bunch of standalone machines all with the same > IP address (10.0.0.1, or whatever). In this case, the license key will > work on all these machines, which is probably not what you want. There's > also people who use dialup SLIP/PPP for their network access who may > get a different IP address assigned to them each time they dial in to > their ISP. Unless you plan on incorporating the host ID in the vendor supplied key (a stupid idea, if licences are transferrable to licensees), then it is irrelevent that the license could be reused on a standalone box. Any license can be reused on a standalone box. > > In point of fact, there was a recent discussion on the SCO and Linux > > ABI front that determined that you could get ethernet hardware addresses > > for any given real ethernet interface using one of the ABI routines. > > So you can forget about having to grovel kmem. > > Well we can read the system hostid via sysctl() (or via gethostid(), > which probably just calls sysctl()); the problem is that it's never > set. It would be simpler just to have the kernel set the hostid > based on the MAC address of the primary interface (if there is one). > The problem is that then any idiot (well, any idiot with root privs) > can use sysctl to change the hostid to anything he wants. Or any idiot with sources can adulterate the gethostid() interface to return whater is convenient for it to return to enable spoofing of the license manager. The only system interface which returns an even somewhat unique ID that is even somewhat difficult to spoof is the ifconfig data interface. > Also, just supposing you have a guy with a machine that -- horror or > horrors -- has no network interface (no ethernet, no ATM, no nuthin'). > Whatcha gonna do then? Not a problem for workstations since they all > come (well, most all) with a network interface of some sort, but that's > not strictly true of PCs. Sell him the non-network version of the product? > Alternatively: ever see the 'twiddle with your hostid' package for > SunOS/Solaris that's floating around? There are tricks there not only to > change your hostid on a _per_ _process_ basis, you can also fake up IP > addresses on a per process basis too. This involves some specially > constructed loadable kernel modules. The idea is to make the id unique *for the license server*. We care less if the id isn't unique for client machines. Even then, I've already admitted that it's hackable. *ANYTHING* is hackable. Hell, a PGP dongle is hackable, if I'm willing to build muxing hardware and/or RPC "dongle services" because I happen to have kernel source. Obviously, the point is "good enough to discourage the casual pirate", not "software enforcement of contracts". > What if they're standalone machines. Then they don't need a license manager in software. They need an SPA audit, o they are unenforcible. > > 3) You could safely hack the ethernet address return interface > > and no one would be the wiser because no system software > > components really depends on it. > > If you had a standalone machine or your own private network, you could > change your IP address at the drop of a hat too. Yes, you could. What is your point? I mean, I could go on and on with this whole "what if" scenario: "What if they hacked the IP?" "Don't let the software and the license server run on the same IP." "What if they are on a standalone machine?" "Use an RSA signing dongle." "What if they build an RPC system to export the dongle signing services over the net?" "Issue keys with the network address included in the hash calcualtion." "What if winged monkeys flew out my butt?" "Call Dorthy and Toto and use duct tape as a workaround." etc. The "license/security" game always boils down to: "We publishers are smarter than you crackers" "We crackers are smarter than you publishers" "No you're not" "Yes, we are" "Are not" "Are too" "Ut-uh" "Uh-huh" "Ut-uh" "Uh-huh" ... The best you can hope for is to reasonably discourage people who look at issues of piracy as cost-benefit calculations, and raise the cost as high as you can raise it. In that situation, license managers are useful. The do not have to "perfectly" solve the piracy problem to be useful. It matters only that they are useful. > This is 'sort of' using IP addresses, except > the actual address values don't matter, which is neat because you can > change the IP address of one of the license servers (or even replace > it entirely) and everything will still work. You can still hack it, however, and that's the argument people keep trying to use against me. Only I don't care if it can be hacked, only the per-product probability that it will be hacked. Hell, you can hack FrameMaker licenses with "mv". Let's se you remove *that* hole -- what good's a system without "mv"? > This assumes, however, that all your machines are all connected on one > network. If you have ten standalone machines, you can buy a single user > floating license and then install the license server on each machine. Since > they can't talk to each other, there's no way for them to tell if the > same license password is being used somewhere else. Same thing applies to > ten machines networked together in isolated groups. Each group could have > its own license server. Also, you might be able to use the same license > file on two networks which are connected but which are not within broadcast > range of each other. The point being that license managers should not be used because of this? I don't buy that. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609252356.QAA07038>