i got a little program that i want to send it to some other peoples.
But i want to prevent that they can easily share it with others.
Is there some easy protection i can use? It doesnt need to be unhackable, just a little protection that you cant just send the app around.
It can't be uncrackable anyway :) There are lots of different protections that you can use, but it always come down to the skill of the reverse engineer.
A pretty standard technique is to pack your software with a packer like asprotect, armadillo, aspack, upx, there are tons of options. This would make it difficult for them to hexedit your software, debug and disassemble it.
If you want to use a serial protection, there are lots of things you could do. One of my favourites is using the key to dynamically decrypt preencrypted blocks of code and execute them. This is called polymorphism and along with self modifying code, it can be a pretty frustrating protection.
If you want to keep things really simple, you could just create a xor protection where correct_serial XOR constant == another_constant. Using constant XOR another_constant, you could simply create a key.
Really tons of things to do here, it's always a matter of taste and knowledge.
There are lots of free solutions, most are crackable. In spite of popular opinion, modern dongles can be 1) trouble-free and 2) uncrackable. But they can cost $25-$100 each, so not a good choice for low-value software.
the use of keys is frequently tied to symmetric key encryption of the .exe so it can't be easily copied. The key is unique to the installation, and can be created by tying it to the machine characteristics like CPU serial number, MAC address, HD serial number, etc. You can also build a small table of those fingerprints and register that user/SN with that table; then have the app "phone home" from time to time to compare to a server DB. Both these methods are crackable, but you said you weren't looking for something unhackable. Downside of HW fingerprinting is that it can fail when the user upgrades the net card or HD. then you have an unhappy customer because they paid for the license and it won't run.
There are MANY approaches to this, this is one:
Create an authentication web service.
Get your app to generate a unique key from something that identifies the machine.
This gets sent you you and you generate a companion key that your app can verify against its unique key.
As you can imagine this is not something you quickly add in. It requires infrastructure and management, which is tricky.
Related
In my project (windows desktop application) I use symmetric key in order to encrypt/decrypt some configurations that need to be protected. The key is hardcoded in my code (C++).
What are the risks that my key will be exposed by reverse engineering ? (the customers will receive the compiled DLL only)
Is there a way for better security for managing the key?
Are there open source or commercial products which I can use
Windows provides a key storage mechanism as part of the Crypto API. This would only be useful for you if you have your code generate a unique random key for each user. If you are using a single key for installations for all users, it will obviously have to be in your code (or be derived from constants that are in your code), and thus couldn't really be secure.
What are the risks that my key will be exposed by reverse engineering ? (the customers will receive the compiled DLL only)
100%. Assuming of course that the key protects something useful and interesting. If it doesn't, then lower.
Is there a way for better security for managing the key?
There's no security tool you could use, but there are obfuscation and DRM tools (which are a different problem than security). Any approach you use will need to be updated regularly to deal with new attacks that defeat your old approach. But fundamentally this is the same as DRM for music or video or games or whatever. I would shop around. Anything worthwhile will be regularly updated, and likely somewhat pricey.
Are there open source or commercial products which I can use
Open source solutions for this particular problem are... probably unhelpful. The whole point of DRM is obfuscation (making things confusing and hidden rather than secure). If you share "the secret sauce" then you lose the protection. This is how DRM differs from security. In security, I can tell you everything but the secret, and it's still secure. But DRM, I have to hide everything. That said, I'm sure there are some open source tools that try. There are open source obfuscation tools that try to make it hard to debug the binary by scrambling identifiers and the like, but if there's just one small piece of information that's needed (the configuration), it's hard to obfuscate that sufficiently.
If you need this, you'll likely want a commercial solution, which will be imperfect and likely require patching as it's broken (again, assuming that it protects something that anyone really cares about). Recommending specific solutions is off-topic for Stack Overflow, but google can help you. There are some things specific for Windows that may help, but it depends on your exact requirements.
Keep in mind that the "attacker" (it's hard to consider an authorized user an "attacker") doesn't have to actually get your keys. They just have to wait until your program decrypts the configurations, and then read the configurations out of memory. So you'll need obfuscation around that as well. It's a never-ending battle that you'll have to decide how hard you want to fight.
I searched a lot about what is the best way to secure your program and I found many results and there were two good ways.
The first one is to hash the mac address of the computer and link it with an activation code but it's still vulnerable.
And the second one is to use a usb device but I didn't find any detail so can anybody tell me in details what is the best way and how to implement it please.
First of all, you need to consider that it doesn't matter what you do, someone will be able to crack it, and because of this is that you need to consider a balance between the security of your application and how hard you will make it for legitimate users (since you don't want to punish a user who already paid for your product, just because you want to protect your applications from the guys who don't want to pay).
Having this in mind, you could go with digital signatures using asymmetric encryption, where you'll sign your license "activation" with your private key, and then your application will use its public key to verify that the received license was submitted by you. You should also take a look at this discussion (I recommend you to focus on the 2nd answer, not the selected one) and this one.
But again, your objective should be to just make things hard for bad guys, but without punishing your legitimate users, because for an attacker, it could be as easy as de-compiling your program and removing your logic to validate the license (unless you're creating an "always online" application, but usually users don't like that, and I'm saying this as a user).
We have a business requirement to keep credit card data. What is today's (Nov 2013) state of the art algorithm to encrypt credit card data that will be saved on disk?
Additionally, I'd appreciate pointers to Java libraries that implement these algorithms
Note that we are PCI compliant and we already store credit card data. I am doing a review to make sure that our encryption method remains state-of-the-art
I recently just left the credit card industry as a developer to work in security in non PCI compliant field. BCrypt is a great choice. It allows a one way hash as well as a work parameter that forces time per attempt. This allows you to stop brut force attacks.
I would use one of the block ciphers approved by ISO/IEC 18033: AES, Camellia, and SEED.
It's hard to go wrong with AES256.
Just go ahead with AES 256 but make sure you choose right mode. I don't agree with comment "It's hard to go wrong with AES256." Check out - https://pthree.org/2012/02/17/ecb-vs-cbc-encryption/
Needless to say, you need to take care of key management and avoid any issues with IV- a message "hello world" encrypted with a key1+IV1 combination will look exactly the same in ciphertext every time you run your encryption. So make sure you are choosing your IVs randomly from a large entropy pool
From Java implementation perspective, Java has native support for AES encryption. Just make sure if you are using 256 bit encryption, you have the right unlimited strength JCE files - without these JCE files which provide crypto methods, you will be limited to 128 bit encryption.
Checkout this if you don't want to reply upon these JCE files available on server running your application.
As #gauravphoenix points out, it is actually quite easy to go wrong with AES. The AES algorithm itself can only securely encrypt exactly 16 bytes of data if you give it a totally random key. If your problem is anything other than that (and almost everyone's problem is something different than that), you need to add more pieces to it. Specifically you need to choose an appropriate mode, configure that mode correctly, properly generate a key, and protect against modification. AES does none of this for you automatically, and unfortunately, most example code on the internet does it incorrectly.
There are a few libraries that attempt to bundle all of these details for you so that you can just make the silly "please encrypt this data" call that most people would like to make. I maintain one for iOS called RNCryptor. There are a bunch of ports of the format to other languages, including a Java implementation called JNCryptor.
Another good "whole solution" AES implementation is aescrypt, which includes a Java implementation.
Note that the most important technical(*) step of securing the data is not your selection of algorithm or format. It's how you manage the keys. If you store the key on the same disk as the credit card numbers, or hard-code it into your software, then it doesn't really matter how strong your encryption is. The state of the art in key management is called an HSM (Hardware Security Module). Companies like SafeNet make them. They can be rack-mounted, plug-in cards, or even USB dongles. I've worked with the Luna, and was generally pleased with it, but there are several options on the market.
(*) While key management is IMO the most important technical step, it is by far not the most important step in securing credit cards (or anything else). The most important step is having procedures in place that encourage secure design, pre- and post-release security review, and a commitment to remediation of security findings.
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.