I've been pondering online product activation for a piece of software, but don't want to overburden the end user. Specifically, I'm concerned with handling the case when the user needs to reinstall the software in the event of hardware failure or upgrades.
I'm not attempting a Fort Knox of security, I don't plan on this application taking the world by storm.
Here are my thoughts, although my thinking may be off:
Assume the program must be connected to Internet to function and standard product activation techniques are applied.
At program install, during license activation, the program could generate a key based on hardware configuration.
This key would be transmitted to the server during activation.
If the license is for one active install, and a second install is attempted - the server invalidates the first install. (This would be caught when the application is restarted on the first computer.)
If a third install were attempted, it would invalidate the second install... and so on.
Ideally, there could only be as many active installs as their license was good for. But, newer installations would invalidate older ones.
Is there a method similar to this in use?
(I'm not exactly sure what to search for, but I've been reading general product activation questions.)
Additionally, is this a valid solution to the 'I upgraded my PC and had to reinstall the program' issue?
Related
We (ISV) are currently planning to offer our software on a rental/subscription basis as a service.
It's a native Windows (C++ / .NET) B2B application.
Our software needs access to the file system (drives) on the customers computer and it also needs access to the network (e.g. be able to find other computers in the network).
We want to offer our customers a service where they do not have to bother themselves with setup/updates and always work with the newest version of our software. So we need a single point of maintenance.
In the first phase we do not expect a lot of our customers (let's say 20) to change to this model, so it would not be a problem to have to set them up and manage them manually, but in the long run a solution that allows an automated set/sign up process would be required.
What I found most promising was Citrix XenDesktop/XenApp with VM hosted Apps and personal vDisks, but it seems that the Citrix solution is not able to get access to the network on the client PC (I tried it with the trial in the Azure Marketplace). Also it seems to be high priced.
What would be other possible ways to meet these requirements?
Unless you can make some significant architectural changes to eliminate the need to access the local filesystem and and eliminate the need to do local network browsing, I would recommend focusing on optimizing your local installation and update process. And skip the virtualization/service idea "for now".
You can still go to subscription model with a locally installed application. Just require your application to "phone home" to check its licensing/subscription status on startup.
Similar questions: Best way to generate activation codes for software and How to generate a simple registration code,based on input given by the user and verifying it after installation
My question/use is similar to that of how Microsoft handled the All-in-One Vista disks. During the Vista install, if it did not detect a specific version to install, it asks for a keycode, then knows which version to install. My application is in Visual Basic 2010, and I would like to use keycodes to have the user unlock certain features based on what code(s) he/she has. So the code needs to be built into the software (or rather, an algorithm) so it knows what to unlock, but not be obvious enough that a black hat hacker knows that bit #xx unlocks feature xxxx. If someone posts code from another .NET or PHP, then I can translate to VB code.
My goals are to not have the codes easily guesses, and still have over 20,000 codes generated that can be converted into a set of features, plus verifying it's a unique user registering or activating the software
In direct response to your question I would take a look at this project; it may be relevant to what you are trying to do: http://keygen.codeplex.com/
However, since you are not installing an OS and instead installing an application I would recommend using a server based DRM setup. The flow for something like this would be:
You generate a new key on the server and include it with the software (or send it via e-mail if it is downloadable content). Part of this generation process includes specifying the features and versions compatible with that key.
The user installs your software and enters the key you provided.
Your software checks with your registration server to see if it is a valid key and to get feature information from the server.
This solution ensures that it is impossible to modify/create new keys without access to the server. If you are using something like GUIDs on the server side then it also makes it virtually impossible to guess at a key.
I am using Installshield for the installation of a product.
I am attempting to find a way to verify an active internet connection before I continue with the installation of my product.
I checked all over, even the manual/help guides from the Installshield people.
I am setting "Program Features" through the Installation Designer->Setup Design->Program Feature(s), and figure if anyplace, it would be in here.
Has anyone worked on this before, and found a viable solution?
ps: I am also trying to find a way to check for minimum system requirements as well (NOT THE O.S. Version, just simple things such as minimum physical memory and minimum RAM)
Much Appreciated,
-Kyle
It's possible, but I wouldn't do it in an install, I would do it in the application as the state of the internet connection could change after the install is performed.
I'd also want to clearly understand why this is required before implementing it. For example I have no direct internet access ( by design ) where I do my software development for security purposes. If I couldn't install or run software because of that, I simply wouldn't buy the software.
Then there are security implications of software applications and installs phoning home and hence why I stay disconnected from the internet on certain machines.
That said, to test for an internet connection, you first have to define what that means. Perhaps you have a public web service that you want to invoke?
this is my first question so please be gentle...
I am working on a software which I would like to protect using some kind of licensing scheme.
A basic scheme would be to generate some "unique" key for a user. The user sends this key and a registration code when he wants to register the software and receives an activation code.
When the application runs it validates the activation code by comparing the "unique" key and a datablob received by decrypting the activation code.
This is fair and quite simple to implement, one can choose different crypto algorithms etc. however this scheme lacks two properties:
If the user manages to spoof hardware signature etc. to produce the same "unique" key on another computer he could use the same license data.
If the user decides to uninstall the application and wants to move it to another computer, there is nothing that prevents him from using the old license data again at the old computer and still obtaining new license data for the new installation.
Do you have any suggestions on how to resolve these issues?
One idea I had was to add some random data to the "unique" key, this random data would be stored in an obscure way, if the user deinstalls the application this random data would be removed, and some kind of hash with the previous random data and the license data would be generated which could be sent to me to verify that he really have uninstalled the application and made me sure that he wont be able to use the previous license data again since the random data had changed.
Over and out, for now...
EDIT:
I currently have a scheme that works, I should mention that the most common product is installed in an embedded enviroment where hardware-changes are very rare and if there is a hardware failure then most certain the machine is broken. But I could modify the hardware-key scheme to take into account and allow for some changes.
Also because of this the software will most likely not be run inside a VM, good point though and I haven't thought about that.
The application does not call out regularly, if a network connection is available the user gets the option to make a more automatic registration, otherwise he/she gets a registration key, enters it in the software and gets an installation ID which is provided to me, registration code + installation ID generates an activation key that the user gets from me which then unlocks the software.
What I am looking for is good/feasible solutions to the 2 points. Hardware spoofing, Revoking license keys i.e. to be sure the user can not use the same regcode+activationcode.
Thank you for all your feedback
It is not necessary to
First, you should make it clear what you're trying to protect. Apparently, you want to ensure that for each purchase of your application, there will only ever be one computer on which the application is installed and runnable.
You propose to use a hardware signature as part of each user's unique key. What happens if my hardware fails (e.g. my hard disk breaks)? I'm certainly not going to purchase your application if I can't go on using it after a hardware problem, so at a minimum you must be prepared to handle key change requests. You'd better respond fast, because if your application is important I want to minimize downtime. And I'm not inviting you to check that my hardware has failed, so you'll have to take my word for it. That means any user can get a free licenses from time to time by pretexting a hardware failure.
What about virtual machines? It's probably feasible to detect all currently existing virtual machine configuration, at the risk of a few false positives now and then. If you forbid virtual machines, how do you justify this to users? If you allow virtual machines, how do you prevent the user from making multiple copies of the whole VM? (This can happen even with physical machines, with hibernation).
Is the application going to call back to you every time it starts? I guess so, from your deinstallation scheme. That's a bandwidth and availabilty cost, and will also put off some users — not everyone is online, especially in sensitive environments. But then you don't need such a complex scheme: your server can keep track of how many copies of the application are running, though you do have to handle the case when the application doesn't terminate cleanly for any reason (application crash, OS crash, power failure, loss of connectivity...).
You don't discuss this in your question, but you have to protect the application executable, so that someone can't bypass the license check with a debugger.
Place your software into appliance hardware and put a padlock on the hardware. Ship the appliance to the customer.
If you believe the customer will hacksaw the appliance open to get your code, consider encrypting the storage medium.... Then they have to hacksaw the box AND find the keys. A TPM chip or secure USB token may aid with the latter.
Being a shareware author and longtime member of ASP myself i think you are going into the wrong direction with your solution. The only way to make this workable is with a hardware device as already suggested. This or constant online activations is the only way if you want to be sure and your product is so good and without competitors that your customers will still use it.
But what we (organized small ISV's) learned from practice is that you should not do what you are trying to do. Do not bind it to hardware. Sell one license per person not one license per computer. In the end you will make more sales because of the relaxed license.
Just do enough to make the honest people stay honest. So limit the trail version (i decided to terminate the application after one hour for me) and leave the final version free from all stuff. Give a separate download for payed customers and thats it. Be a nice company and not a greedy profit maximizing by legal restrictions company.
I used some of the better windows protection programs first but they all had serious problems with my code. And they call get cracked sooner or later. So i gave up all of them.
P.S.: I use a hardware fingerprint schema on windows where i don't restrict the program but just to keep people away from getting new trial keys every 30 days. Together with a nag screen it seems to work. The fingerprint is an xor of user name, windows installation time, modify time stamp of a system files and harddisk serial id.
Let the registration code also be the activation code.
You generate the unique registration code at point of sale, or packaged with the product. Customer registers/activates/deactivates with you (or your server) in one step using that single code. The customer's hardware doesn't have to generate any keys.
Reregistering/reactivating still requires contact with you, so you're aware of reinstall attempts.
I think that the only solution to your problem is a cryptographic hardware dongle. Usually it would be a USB-based tamper-resistant challenge-response dongle, that can be easily transferred between computers.
These devices cost less than $1 for large quantities, and not more than $10 for very small quantities. The good ones are very hard to forge, very easy to embed in your application, and usually supplied with a free EXE encryptor which also contains anti-debugging and anti-reverse-engineering functionality.
A customer wants their product to require users to enter a machine-specific code, so that they can only run it on one machine... if they want to use it elsewhere they get a deactivation code from the first machine and send that back to prove this.
If the app could talk to their server this could be made much smoother but this is not the case. I thought of a workflow but it's a bit convoluted:
Customer purchases a license and is emailed a serial code
Customer installs App and is prompted for serial code
App generates a machine-specific code and performs some operation combining this with the serial code, providing this PC-Code to the Customer
App now requests an Activation code, once entered it will run
Customer sends PC-Code to Vendor who check it's valid against their recorded serial code, and using both generates an Activation code which they send to the Customer
The idea is PC-Code and Activation Code are both short, more like pin-numbers, so it's not too horrific... but is there a better system? And how can specific steps be implemented?
I personally don't like restricting the customer so much but it's not my call, it's been argued to death already :)
By using an activation code step you are effectively forcing the customer to be your internet connection. Unfortunately without this step you can't tie them down to a machine.
The biggest problem is going to be your deactivation code - if the customer writes down their activation code what's to stop them using it to reactivate their PC again?
The only way would be to have your activation code somewhat based on date so that they get a week or month to enter it. They'll probably never notice an issue unless they need to a reinstall in which case you can reissue another activation code (provided there isn't an outstanding non-deactivated code for a different machine).
How programming-competent are your customers and how motivated will they be to crack your software?
This article provides some good ways on getting hardware information.
This is why hardware keys are used, you cannot physically plug it into two devices at once. The only method with software requires a trusted third party to manage quorum, i.e. authentication servers over the Internet.
One popular unique identifier for Unix licensing is the hostid. A modern alternative would be to include a secure token generator such as the RSA SecurID. Have the administrator read the token over the phone to the vendor, pass through some algorithm to generate a key to unlock the software.
Everything else is going to be smoke and mirrors.