There is a Windows program which is downloaded after entering a valid serial in a web page. Now, I want to limit the user to install the program only on one single PC, the one he or she installed for the first time.
I need some advice on creating a such system. Thank you.
P.S. Serial key must be entered on the web page instead of the installer.
Sounds like you need to create a downloadable activex control program that will run on the client's machine in which it will interrogate:
MAC of network adapter
Windows Version, including SP
Hard disk serial number
Processor make and CPU type
And relay the information back to the website, then generate the key, and attach the key to the download installer and permit the user to download the installer in which the key is then read in at run-time and checked against the machine that is running on.
The only thing is the ActiveX must be written in C/C++ as you cannot do it on the .NET language as that is assuming the client's machine will have the runtime installed which IMHO is a dangerous assumption.
Hope this helps,
Best regards,
Tom.
The usual solution is:
Create a hash describing the system (don't know the exact way to get it though, GIYF) & combine it with the serial, so when the user installs the program he has to enter the serial, then gets a key he has to enter on the website which splits the entered key into the serial and the system hash and checks if the system hash and serial match the stored ones and then returns another key (or an error if the serial was already used) he has to enter into the program.
Using the Mac Adress as a system key is not a good solution as it can easily be faked.
Base the serial number on some hardware configuration. If the hardware changes, then invalidate the serial number. Microsoft windows uses this type of approach during the activation of the product.
Hope this helps some.
If you write a custom installer then you could send an acknowledgement to your web server upon successful install that sends a serial # generated from the hardware, and the serial # they used to download the file.
Then if you find the same serial # but a different hardware serial, you can send a response back saying that you could not activate the software...
EDIT
Here is some info on getting hardware info (assuming a .NET environment, but you can find similar for the environment you are using).
You could try blocking the key on install and unblocking the key when they uninstall. That way they can only use the key once between each uninstall.
set up a web service and database ... they have to validate to be able to install. the problem with your model at the moment is that you are protecting or hiding your software behind the server. You want peopel to have the software even if they cant use it (usually). the serial key stage should be there to unlock the software at runtime.
Its the only model that works for computer games.
You need to poll various pieces of hardware to generate a guid, hash it against a product key and you have a reproducible yet complex and hard to forge piece of data.
http://edn.embarcadero.com/article/26040 A link to the .com interfaces to get at the guids
an alternative would be to use something like sysinfo or dxdiag and save the rseults to a file ... hash it and use that as the serial. A lot less coding involved - but a bit messier.
Store this and issue the installation key - easy to spot and manage reinstalls then.
Ie you really don't want to go 'computer says no' - its really a marketing opportinuty
Related
It has come to my attention that code signing certificates are from now on required to be paired with physical tokens.
The Minimum Requirements specify that CAs shall ensure stronger protection for private keys. As such, all Code Signing Certificates, not just Extended Validation level, will require a USB token starting on January 30, 2017. With this, all New and Renewal Standard Code Signing orders will be sent a USB token to store the certificate and protect the private key. Also, all standard Code Signing products except for EV Code Signing will be integrated to one “multi-platform” Code Signing Certificate.
Note: Reissues of existing Code Signing Certificates (issued prior to 30 January 2017) will not require a token right away. However, this is subject to change.
As someone who uses a cloud-only workflow, this raises an obvious concern for me - I cannot just plug this USB token into "the cloud".
Do I understand it right that I will from now on need to set up a separate on-premise code signing process? Or is there some possibility remaining for signing code in the cloud? What are the expectations I should have for working under the new rules?
Based on the article you linked it sounds like you will absolutely need to provide your build system access to a USB key in order to sign your artifacts. As you mention the obvious solution (and probably what Microsoft is attempting to encourage) is to set up an on-premise build system that gets used exclusively for code signing.
From a security point of view this is probably the best option since you could harden that machine both in terms of software but also in terms of hardware (e.g. locked in a closet in your work area). But this might also not be realistic depending how your build system is set up.
Your other option is to use a USB forwarding solution to forward the USB key to your cloud environment. There are a lot of ways to do this and the best one is going to depend on what you're building and on what operating system(s) but here's a rundown of some options:
Linux systems - USB/IP - This is a kernel module and userspace application provided with a good number of Linux distributions (it's a mainline module, but not always included). This lets you take a local USB device and forward it over the network to another Linux machine. I've had pretty good luck with this but setting it up the first time can be a little tricky.
Windows Systems - RemoteFX forwarding over RDP - On newer Windows systems (Windows 10, Server 2012 R2+) Remote Desktop supports USB redirection natively. You can simply forward the USB key through a RDP session. This would require you to remain connected at all times while building though.
Windows Systems - Third Party Software - There are several third party USB forwarding solutions available. For instance this one. Some of these have the advantage of being able to run without requiring an active desktop session.
The gotca with all of these solutions is that if the USB token is designed to actively prevent this (or is somehow otherwise incompatible with forwarding) it may not work. Some license keys for instance will check to make sure the timings to/from the computer are within a certain tolerance for instance. In those cases the added latency from the cloud to your machine would cause the token to not work. It'll all depend on the USB key you get sent.
The whole point of policies like this is to prevent you as the keyholder from accidentally losing control of your key material by giving you something you must physically possess in order to use your key. Cloud build systems are convenient but tend in general to have a much wider security landscape which makes securing keys trickier than on-site systems. It looks like Microsoft and your CA are attempting to prescribe how keys are being handled.
Microsoft provides a method to get an ASHWID (App Specific Hardware ID) which has many components, one of which is some kind of BIOS ID.
http://msdn.microsoft.com/en-us/library/windows/apps/jj553431.aspx
Does that BIOS ID change if the user upgrades the BIOS on their computer?
RANT:
I don't understand why Microsoft makes getting a unique ID for an OS installation so complicated for Windows Store Apps. Android is so simple, when the Android OS boots the very first time they generate a GUID (see http://developer.android.com/reference/android/provider/Settings.Secure.html#ANDROID_ID) that never changes. Why doesn't Microsoft do this?
First of all, that value changes with factory reset in Android.
Second of all, try checking out EasClientDeviceInformation.Id. It uses a combination of the MachineId (local user group SID), the UserId, and the Package Id, but doesn't give you the whole thing.
This is good because Thirdly, giving devs access to use them directly to generate things like crypto keys can lead to other apps getting your apps keys, like has happened on many iOS devices. By limiting what device id's you can use, they're making it so that you must use a system resource that is literally only accessible from inside of a given application with a given Id from inside that user's account. The Windows Store is very strongly sandboxed for exactly this reason. While it can be a pain sometimes, it makes the platform much more secure, which is a huge boon.
I ran set up files for Dotfuscator Professional Edition 3.0. after running setup it takes input from user to complete registration. Then after completing registation it asks user for serial number. i mistakenly input the wrong serial number. if i open it now it gives me following error.
Invalid Dotfuscator Serial Number. Please contact your vendor
after clicking Ok it closes the application. i tried re-installing software (in hope that it will ask me for serial key again) but picking already entered wrong serial numbers. i also had tried deleting old registry values.
I dont want to format my machine right now to complete its removal and this software is must.if i again install windows it will eat up my whole day with all softwares.
can anybody suggest something. i want this to completely install and then install and activate it with correct serial number.
You should be able to correct this by deleting your "Dotfuscator.dat" file, which is located in
"C:\ProgramData\PreEmptive Solutions\Dotfuscator Professional Edition\3.0" (or the equivalent for your operating system).
I know registry is not a best place to hide something.
Right now I'm writing a Licensing software that require to save trial usage information like first install date on registry, etc.
What hive in Windows Registry that meet this criteria :
Not easily discovered by accident by the Users.
The value can be shared among Windows Users.
Didn't mess up Windows and Registry Cleaning Utility not consider this value as a garbage.
If can, it work without administrator privileges on Windows Vista and Windows 7
Edit : I have excluded items # 4 because it is not possible with item # 2, based on answers from David Heffernan
There are no shared locations in the registry that can be written to without admin rights. So your conditions 2 and 4 cannot both be fulfilled. You need to do this with a file I believe.
If you are prepared to drop condition 4 then you need to store it under HKLM so that it is shared. The obvious place is HKLM\Software\YourCompanyName\YourProductName. Naturally you would encrypt the data to avoid tampering. Once you have done that then you don't really care whether or not your users discover it.
What are you trying to defend against? It sounds like you're putting a lot of effort into "don't let people change their system clock to extend their trial" but none at all into "don't let people edit the Registry key to extend their trial" or "don't let people share Registry keys between machines to turn trials into full keys for free". I actually think those are far more likely. Any software that yelled at me for changing the clock on my own machine would get uninstalled in a hurry.
I recommend you don't try to do this yourself. There are licensing libraries you can use that have thought of the various ways people try to trick software. But if you must, because you want to try it, then take some time to distinguish what happens at install, which might require admin rights, from what happens while you're running and checking, which should not. An app that has to run elevated for no other reason than writing license info to HKLM once a minute would also be uninstalled in a heartbeat from my machine.
So at install, write something obscure/encrypted to a Registry key under HKLM. Make it something that's not super helpful to copy from machine to machine, while you're at it, by combining say a date, an email address, and some other information. At runtime, your code should look partly at the unchanging Registry entry or entries and partly at something else that can change easily, like a file under AppData, an HKCU key, or the current date, to decide whether it's ok for the app to run. (At runtime, if the HKLM key is not there or fails a checksum or whatever, refuse to run and ask for a reinstall. Reinstall can worry about whether the person is trying to get infinite free trials.) Focus on the main ways people try to trick licensing schemes and also on being a usable application. Insisting on elevating or preventing general use of the machine fails on the usability side.
You can, on install, change permissions of somewhere in HKLM so that all users have write access.
If you choose a place other than HKLM\SOFTWARE\Your Company Name\something than you're being foolish.
If you want to implement a time limited trial for an application you would probably want to leave behind some flag (registry key, file etc) so a program couldn't just be re-installed.
Are there any schemes that allow you to do this while still passing the various Windows Certification programs?
Generally :-
Applications must correctly and fully
uninstall from the machine. This
includes removing files, registry
keys, GAC assemblies, database tables,
metabase settings, active directory
accounts, etc. Anything left on the
system after uninstall, including
system components installed by the
application, must be documented and
justified - Windows Server 2008 Software Logo Secification - 2.3 Uninstall Cleanly
You are taking the philosophy of only allowing installation if a flag is NOT there, which means you need to leave the flag there after uninstall. Also this fails when the user finds the flag and deletes it themself.
Better is if you turn it around and only allow the program to work if a flag IS there. This flag would be a registration key that has the date of expiry encrypted into it. When the program expires or is uninstalled, you delete the flag.
I implement this by making my users come to my site to register and get a free trial key. There are probably other ways, but I like this one because it also allows me to collect info about who is trying my program.
If your app is connected to the Internet, then you could store information on your own server about whether it has been installed before or not. However, this almost certainly needs to be designed in from the start with potential investment in hosting your own server to be available to check against.
I'm sure there must be plenty of cases where files are left behind after an uninstall that are perfectly acceptable. For example, I wouldn't expect all my documents to be deleted when I uninstalled Word.