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.
Related
Can a running nodejs program cryptographically prove that it is the same as a published source code version in a way that could not be tampered with?
Said another way, is there a way to ensure that the commands/code executed by a nodejs program are all and only the commands and code specified in a publicly disclosed repository?
The motivation for this question is the following: In an age of highly sophisticated hackers as well as pressures from government agencies for "backdoors" that allow them to snoop on private transactions and exchanges, can we ensure that an application has been neither been hacked nor had a backdoor added?
As an example, consider an open source-based nodejs application like lesspass (lesspass/lesspass on github) which is used to manage passwords and available for use here (https://lesspass.com/#/).
Or an alternative program for a similar purpose encryptr (SpiderOak/Encryptr on github) with its downloadable version (https://spideroak.com/solutions/encryptr).
Is there a way to ensure that the versions available on their sites to download/use/install are running exactly the same code as is presented in the open source code?
Even if we have 100% faith in the integrity of the the teams behind applications like these, how can we be sure they have not been coerced by anyone to alter the running/downloadable version of their program to create a backdoor for example?
Thank you for your help with this important issue.
sadly no.
simple as that.
the long version:
you are dealing with the outputs of a program, and want to ensure that the output is generated by a specific version of one specific program
lets check a few things:
can an attacker predict the outputs of said program?
if we are talking about open source programs, yes, an attacker can predict what you are expecting to see and even can reproduce all underlying crypto checks against the original source code, or against all internal states of said program
imagine running the program inside a virtual machine with full debugging support like firing up events at certain points in code, directly reading memory to extract cryptographic keys and so on. the attacker does not even have to modify the program, to be able to keep copys of everything you do in plaintext
so ... even if you could cryptographically make sure that the code itself was not tampered with, it would be worth nothing: the environment itself could be designed to do something harmful, and as Maarten Bodewes wrote: in the end you need to trust something.
one could argue that TPM could solve this but i'm afraid of the world that leads to: in the end ... you still have to trust something like a manufacturer or worse a public office signing keys for TPMs ... and as we know those would never... you hear? ... never have other intentions than what's good for you ... so basically you wouldn't win anything with a centralized TPM based infrastructure
You can do this cryptographically by having a runtime that checks signatures before running any code. Of course, you'd have to trust that runtime environment as well. Unless you have such an environment you're out of luck - that is, unless you do a full code review.
Furthermore you can sign the build by placing a signature within the build system. The build system and developer access in turn can be audited. This is usually how secure development environments are build. But in the end you need to trust something.
If you're just afraid that a particular download is corrupted you can test against an official hash published at one or more trusted locations.
I am building a distributed application in which the software is installed by my company on our customer's hardware. The customer can therefore tamper with the software. I would like to know if a technique exists so that when the software running on customer hardware make a web request to our central server (i.e. totally under our control), that we can validate that the request is coming from an untampered version of our software.
I believe that this is referred to as "remote attestation." Web searches about remote attestation return a variety of results, from "it is not possible" to "use the TPM". But I have not been able to find a simple to understand example of how to code this in Windows.
So, my question is: Is remote attestation possible in Windows, and if so, is there a working example that I can use as the basis for implementation?
Note: Remote attestation is sometimes achieved through "obscuration" techniques such as embedding a "shared secret" into the application and then obscuring it in various ways to try and ensure that an attacker cannot easily extract that shared secret through de-compiling etc. I am not interested in such techniques and am looking for something that provides real security not security through obscurity.
In order to attestate a system you need 2 things:
A chain of trust from a root of trust up to every executed code and
Means to interpret and verify the obtained measurements on your server.
When using Windows you have neither.
Currently not even Windows itself is aware of its sate. However, that improved in Windows 8. Now you have measurements of the boot loader and drivers at least. But nothing that extends to user code.
I'm building a Raspberry Pi based valve-amplified MP3 player, housed in a restored Westminster radio case:
http://www.youtube.com/watch?v=oTabLcVgvwo
I'd like to write a simple Free client that starts playing a particular named playlist ('Westiamp', which is the name of the project) immediately. It'll also interface to a USB-connected control panel for skipping between tracks, etc.
There will be a simple web UI for entering username and password to log in to Spotify, and WiFi details.
My question relates to the API Key. There are several options I can see here:
apply for a personal API key, and release it along with the source code
apply for an API key for the project, and release it along with the source code
provide an option in the web UI for the user to specify an API key, and use that
I would much rather not distribute a personal API key, and I don't think usability would be helped by requiring any user of the software to apply for their own key.
Is there a Spotify-approved process here? I've tried posting on the community forum (silence) and asking support (who directed me here).
It's strictly against the Spotify Terms of Service to distribute your key with source code.
If you're only distributing binaries with the C API key compiled in, that's fine. Otherwise, you must require the end user of your code to supply the C key at compile-time, or ask for the binary key at runtime.
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.
I have tried searching, and all questions are related to specific things like "how to generate key", and the like. Can anybody explain how different types of software activation work?
In the most simplistic case, it is as maxwell5555 described. A registration code ("CD key") is sent to the user who enters it into the program or installer. The whole process can basically be done offline; the program itself locally determines that the code is valid or invalid.
This is nice and easy, but it extremely vulnerable to key sharing - since there's no "phoning home" then the application cannot know that thousands of different people are all using the same key that they got off the internet or a serial library or their friend. It's also reasonably easy to make "keygens" which generate valid-seeming keys that were never actually issued by the developers.
Then we get into online registration. You still have some kind of code, but the program will phone home back to the server to determine whether the code is valid and usually unique. This stops basic key sharing, because the company knows if too many people from all over the world are all using the same key. Perhaps there is some kind of indentification involved using MAC address, too, with infinte registrations allowed on the same hardware but maybe a limited number on what appears to be a different computer.
This is still pretty easy and stops simple key sharing. People will actually have to get into cracking the software or faking the server response to get past it.
Sometimes the program itself is partially/mostly encrypted and is only decrypted by the online registration step. Depending on how well this is obfuscated then it can be pretty difficult and time consuming to crack. Bioshock was a high-profile example of this - debuting with a brand new encryption/copy protection scheme that took around two weeks from release to be broken.
Finally, a particularly guarded applciation might stay in constant contact with the server, refusing to work at all if the connection is severed. In this case to get arouind the activation you need to fake the server itself. Steam emulators and private WoW servers are an example of this.
And in the end, nothing is uncrackable.
I suspect a lot of the implementers will not give this information out because it opens them to hacking. But if I were to do this, this is how I would go about it:
Decide if the software is licensed to a person or a computer.
Find a way of identifying the person/computer (login account or ID from the computer hardware).
On request/payment: in your private database, create a licence key and add an entry for the person/PC with this key.
Provide the client software with the key.
Your software either stores the key locally, or regularly checks for the key giving a service of yours the identifying information in return for which your service supplies the key if there is one. If none is found, your software offers them details to purchase a licence. The latter allows for floating keys, computer upgrades, and identifying duplicate installations.
Is that what you were asking for?
A common, simple way of implementing software activation/registration is to create a license algorithm. For example, lets say I have some shareware I want to protect and when someone gives me money, I send them a 4-byte registration code. I could build the algorithm into my shareware such that it validates the code the users enters. My algorithm would be as follows:
1) Byte0 * Byte1 = 6
2) Byte2 - Byte3 = 1
3) Byte0 + Byte2 = 8
Two possible valid codes are:
3254
1676
When the user enters a valid code, the software unlocks its regular functionality by setting a flag somewhere. Obviously, this is an extremely simplistic example. Registration validation algorithms can be as complex as you want.
You can also perform this registration over the internet to protect your validation algorithm from reverse engineering, and keep people from sharing keys. No validation scheme is perfect though.