Develop Reference

C# application which requires access key to activate licence [duplicate]

I'm currently involved in developing a product (developed in C#) that'll be available for downloading and installing for free but in a very limited version. To get access to all the features the user has to pay a license fee and receive a key. That key will then be entered into the application to "unlock" the full version.
As using a license key like that is kind of usual I'm wondering :
How's that usually solved?
How can I generate the key and how can it be validated by the application?
How can I also avoid having a key getting published on the Internet and used by others that haven't paid the license (a key that basically isn't "theirs").
I guess I should also tie the key to the version of application somehow so it'll be possible to charge for new keys in feature versions.
Anything else I should think about in this scenario?

Caveat: you can't prevent users from pirating, but only make it easier for honest users to do the right thing.
Assuming you don't want to do a special build for each user, then:
Generate yourself a secret key for the product
Take the user's name
Concatentate the users name and the secret key and hash with (for example) SHA1
Unpack the SHA1 hash as an alphanumeric string. This is the individual user's "Product Key"
Within the program, do the same hash, and compare with the product key. If equal, OK.
But, I repeat: this won't prevent piracy
I have recently read that this approach is not cryptographically very sound. But this solution is already weak (as the software itself has to include the secret key somewhere), so I don't think this discovery invalidates the solution as far as it goes.
Just thought I really ought to mention this, though; if you're planning to derive something else from this, beware.

There are many ways to generate license keys, but very few of those ways are truly secure. And it's a pity, because for companies, license keys have almost the same value as real cash.
Ideally, you would want your license keys to have the following properties:
Only your company should be able to generate license keys for your products, even if someone completely reverse engineers your products (which WILL happen, I speak from experience). Obfuscating the algorithm or hiding an encryption key within your software is really out of the question if you are serious about controlling licensing. If your product is successful, someone will make a key generator in a matter of days from release.
A license key should be useable on only one computer (or at least you should be able to control this very tightly)
A license key should be short and easy to type or dictate over the phone. You don't want every customer calling the technical support because they don't understand if the key contains a "l" or a "1". Your support department would thank you for this, and you will have lower costs in this area.
So how do you solve these challenges ?
The answer is simple but technically challenging: digital signatures using public key cryptography. Your license keys should be in fact signed "documents", containing some useful data, signed with your company's private key. The signatures should be part of the license key. The product should validate the license keys with the corresponding public key. This way, even if someone has full access to your product's logic, they cannot generate license keys because they don't have the private key. A license key would look like this: BASE32(CONCAT(DATA, PRIVATE_KEY_ENCRYPTED(HASH(DATA))))
The biggest challenge here is that the classical public key algorithms have large signature sizes. RSA512 has an 1024-bit signature. You don't want your license keys to have hundreds of characters.
One of the most powerful approaches is to use elliptic curve cryptography (with careful implementations to avoid the existing patents). ECC keys are like 6 times shorter than RSA keys, for the same strength. You can further reduce the signature sizes using algorithms like the Schnorr digital signature algorithm (patent expired in 2008 - good :) )
This is achievable by product activation (Windows is a good example). Basically, for a customer with a valid license key, you need to generate some "activation data" which is a signed message embedding the computer's hardware id as the signed data. This is usually done over the internet, but only ONCE: the product sends the license key and the computer hardware id to an activation server, and the activation server sends back the signed message (which can also be made short and easy to dictate over the phone). From that moment on, the product does not check the license key at startup, but the activation data, which needs the computer to be the same in order to validate (otherwise, the DATA would be different and the digital signature would not validate). Note that the activation data checking do not require verification over the Internet: it is sufficient to verify the digital signature of the activation data with the public key already embedded in the product.
Well, just eliminate redundant characters like "1", "l", "0", "o" from your keys. Split the license key string into groups of characters.

Simple answer - No matter what scheme you use it can be cracked.
Don't punish honest customers with a system meant to prevent hackers, as hackers will crack it regardless.
A simple hashed code tied to their email or similar is probably good enough. Hardware based IDs always become an issue when people need to reinstall or update hardware.
Good thread on the issue:
http://discuss.joelonsoftware.com/default.asp?biz.5.82298.34

When generating the key, don't forget to concatenate the version and build number to the string you calculate the hash on. That way there won't be a single key that unlocks all everything you ever released.
After you find some keys or patches floating in astalavista.box.sk you'll know that you succeeded in making something popular enough that somebody bothered to crack. Rejoice!

I'm one of the developers behind the Cryptolens software licensing platform and have been working on licensing systems since the age of 14. In this answer, I have included some tips based on experience acquired over the years.
The best way of solving this is by setting up a license key server that each instance of the application will call in order to verify a license key.
Benefits of a license key server
The advantages with a license key server is that:
you can always update or block a license key with immediate effect.
each license key can be locked to certain number of machines (this helps to prevent users from publishing the license key online for others to use).
Considerations
Although verifying licenses online gives you more control over each instance of the application, internet connection is not always present (especially if you target larger enterprises), so we need another way of performing the license key verification.
The solution is to always sign the license key response from the server using a public-key cryptosystem such as RSA or ECC (possibly better if you plan to run on embedded systems). Your application should only have the public key to verify the license key response.
So in case there's no internet connection, you can use the previous license key response instead. Make sure to store both the date and the machine identifier in the response and check that it's not too old (eg. you allow users to be offline at most 30 days, etc) and that the license key response belongs to the correct device.
Note you should always check the certificate of license key response, even if you are connected to the internet), in order to ensure that it has not been changed since it left the server (this still has to be done even if your API to the license key server uses https)
Protecting secret algorithms
Most .NET applications can be reverse engineered quite easily (there is both a diassembler provided by Microsoft to get the IL code and some commercial products can even retrieve the source code in eg. C#). Of course, you can always obfuscate the code, but it's never 100% secure.
I most cases, the purpose of any software licensing solution is to help honest people being honest (i.e. that honest users who are willing to pay don't forget to pay after a trial expires, etc).
However, you may still have some code that you by no means want to leak out to the public (eg. an algorithm to predict stock prices, etc). In this case, the only way to go is to create an API endpoint that your application will call each time the method should be executed. It requires internet connection but it ensures that your secret code is never executed by the client machine.
Implementation
If you don't want to implement everything yourself, I would recommend to take a look at this tutorial (part of Cryptolens)

Besides what has already been stated....
Any use of .NET applications are inherently breakable because of the intermediate language issues. A simple disassembly of the .NET code will open your product to anyone. They can easily bypass your licensing code at that point.
You can't even use hardware values to create a key anymore. Virtual machines now allow someone to create an image of a 'licensed' machine and run it on any platform they choose.
If it's expensive software there are other solutions. If it's not, just make it difficult enough for the casual hacker. And accept the fact that there will be unlicensed copies out there eventually.
If your product is complicated, the inherent support issues will be create some protection for you.

The C# / .NET engine we use for licence key generation is now maintained as open source:
https://github.com/appsoftware/.NET-Licence-Key-Generator.
It's based on a "Partial Key Verification" system which means only a subset of the key that you use to generate the key has to be compiled into your distributable. You create the keys your self, so the licence implementation is unique to your software.
As stated above, if your code can be decompiled, it's relatively easy to circumvent most licencing systems.

I've used Crypkey in the past. It's one of many available.
You can only protect software up to a point with any licensing scheme.

I don't know how elaborate you want to get
but i believe that .net can access the hard drive serial number.
you could have the program send you that and something eles ( like user name and mac address of the nic)
you compute a code based off that and email them back the key.
they will keep them from switching machines after they have the key.

I strongly believe, that only public key cryptography based licensing system is the right approach here, because you don't have to include essential information required for license generation into your sourcecode.
In the past, I've used Treek's Licensing Library many times, because it fullfills this requirements and offers really good price. It uses the same license protection for end users and itself and noone cracked that until now. You can also find good tips on the website to avoid piracy and cracking.

The only way to do everything you asked for is to require an internet access and verification with a server. The application needs to sign in to the server with the key, and then you need to store the session details, like the IP address. This will prevent the key from being used on several different machines. This is usually not very popular with the users of the application, and unless this is a very expensive and complicated application it's not worth it.
You could just have a license key for the application, and then check client side if the key is good, but it is easy to distribute this key to other users, and with a decompiler new keys can be generated.

I've implemented internet-based one-time activation on my company's software (C# .net) that requires a license key that refers to a license stored in the server's database. The software hits the server with the key and is given license information that is then encrypted locally using an RSA key generated from some variables (a combination of CPUID and other stuff that won't change often) on the client computer and then stores it in the registry.
It requires some server-side coding, but it has worked really well for us and I was able to use the same system when we expanded to browser-based software. It also gives your sales people great info about who, where and when the software is being used. Any licensing system that is only handled locally is fully vulnerable to exploitation, especially with reflection in .NET. But, like everyone else has said, no system is wholly secure.
In my opinion, if you aren't using web-based licensing, there's no real point to protecting the software at all. With the headache that DRM can cause, it's not fair to the users who have actually paid for it to suffer.

You can use a free third party solution to handle this for you such as Quantum-Key.Net It's free and handles payments via paypal through a web sales page it creates for you, key issuing via email and locks key use to a specific computer to prevent piracy.
Your should also take care to obfuscate/encrypt your code or it can easily be reverse engineered using software such as De4dot and .NetReflector. A good free code obfuscator is ConfuserEx wich is fast and simple to use and more effective than expensive alternatives.
You should run your finished software through De4Dot and .NetReflector to reverse-engineer it and see what a cracker would see if they did the same thing and to make sure you have not left any important code exposed or undisguised.
Your software will still be crackable but for the casual cracker it may well be enough to put them off and these simple steps will also prevent your code being extracted and re-used.
https://quantum-key.net
How to use ConfuserEx?
https://github.com/0xd4d/de4dot
https://www.red-gate.com/dynamic/products/dotnet-development/reflector/download

I know this is an old question, but I referenced this when I was re-writing my licensing process for one of my applications.
After reading a lot of opinions out there and relying on past experience with license codes I came up with this process.
public static class LicenseGenerator
{
private static string validChars = "ACEFHJKMNPRSTUVWXYZ234579";
private static Random rnd = new Random(Guid.NewGuid().GetHashCode());
/// <summary>
/// Generate a license code
/// </summary>
/// <param name="length">length of each phrase</param>
/// <param name="number">number of phrases separated by a '-'</param>
/// <returns></returns>
public static string GetNewCode(int length, int number)
{
string license = string.Empty;
for (int numberOfPhrases = 0; numberOfPhrases < number; numberOfPhrases++)
{
license += getPhrase(length);
if (numberOfPhrases < number)
license += "-";
}
return license.TrimEnd('-');
}
/// <summary>
/// generate a phrase
/// </summary>
/// <param name="length">length of phrase</param>
/// <returns></returns>
private static string getPhrase(int length)
{
string phrase = string.Empty;
for (int loop = 0; loop < length; loop++)
{
phrase += validChars[rnd.Next(validChars.Length)];
}
return phrase;
}
}
You really don't want to provide a code that has similar letters; it makes for a mess when the end user goes to enter it in. Letters like 6 and G, B and 8, L, I, and 1. Of course if you do want them, you can always add them back in... The above code will generate a license like xxxx-xxxx-xxxx-xxxx using the characters in "validChars". Calling GetNewCode(4, 4) will return a code like above.
I'm using Azure functions to register then validate the code. When my app registers the code, it generates an encrypted hash with things that are unique to the install, device and/or user. That is provided to the registration function and is stored with the key in the DB in Azure.
The validate regenerates the key and provides it with the license code, IP address (which in my case will not change and if it does then it will need to be updated anyway), and the regenerated hash then the Azure function returns if the application is licensed. I do store a "temporary" key on their server that allows the app to run for a period of time without talking back up.
Of course, my app must be on the net for it to work regardless.
So, the end result is a simple key for the end user to type in and an easy process to manage the license on the backend. I can also invalidate a license if need be.

I solved it by interfacing my program with a discord server, where it checks in a specific chat if the product key entered by the user exists and is still valid. In this way to receive a product key the user would be forced to hack discord and it is very difficult.

Where can I store (and manage) Application license information? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am developing a Windows Application. That requires users to register to use it...
Now, I am storing my license info as a file in APpData. But deleting that file resets the trial version date. So, I am now planning to save it in registry.
But, Most of the Users will not have administrative privileges (Limited Users) in Windows to Access the registry.
What can I do ? Where can I save my serial number and date ?

In my opinion the point is you have to change how you manage your license.
Where
If they delete license data file then trial restarts? Do not start application if file doesn't exist and create it with an install action first time it's installed.
Now you face a second problem: what if they uninstall and reinstall application? Second step is to move this file to application data folder (for example Environment.SpecialFolder.CommonApplicationData). This is just little bit more safe (because application data won't be deleted when uninstall) but it's still possible for them to manually find and delete it. If application will be installed by low privileges users there isn't much you can do (you can't try to hide license somewhere in Registry).
Now it's a game between you and crackers. They'll win, always. You'll only make life of legitimate users more hard so read cum grano salis. Where you may store license data:
Registry. Pro: easy to do. Cons: easy to crack and for low privileges user it's valid only for one user per time. A registry key (in a per-user base) can be somehow hidden if it has \0 in its name. Take a look to this nice post.
File. Pro: easy to do and IMO little bit more safe than Registry. Cons: easy to crack (but you can hide it more, see later).
Application itself (appending data to your executable, few words about that on this post). Pro: harder to detect. Cons: an antivirus may see this as...a virus and an application update may delete license too (of course if you don't handle this situation properly) so it'll make your code and deployment more complicated.
How to hide license in a file?
If you're going with a file (it doesn't matter where it's located) you may consider to make crackers life (little bit) harder. Two solutions come to my mind now:
Alternate Data Streams. File is attached to another file and they won't see it with just a search in Windows Explorer. Of course there are utilities to manage them but at least they have to explictly search for it.
Hide it inside application data (a bitmap, for example, using steganography). They just don't know it's license data, what's more safe? Problem is they can easy decompile your C# program to see what you do (see paragraph about Code Obfuscation).
Probably many others (fantasy here is our master) but don't forget...crackers will find it (if they really want) so you have to balance your effort.
How
Keeping your license schema you're now on a dead path. Decision you have to take is if the risk they use trial longer than allowed is higher than risk they stop to use your application because of boring protection.
Validation
If you can assume they have a network connection then you may validate license on-line (only first time they run your application) using some unique ID (even if it's about Windows 8 you may take a look to this post here on SO). Server side validation can be pretty tricky (if you want to do it in the right way), in this post is explained an example of program flow to manage that in a proper way.
Data Obfuscation/Encryption
Your license file/data is now in a safe place. Hardly crackers will find it. Now you need another step: obfuscation. If your license data is in plain text once they found your file it's too easy to change it. You have some options (ordered by increased security and complexity):
Obfuscate your files. If they can't understand what's inside a file with a simple text editor (or even a hex editor) then they'll need more time and effort to crack it. For example you may compress them: see this post about XML file obfuscation with compression. Note that also a simple base64 encoding will obfuscate your text files.
Encrypt them wit a symmetric algorithm. Even a very simple one will work well, here you're just trying to hide data. See this post for an example. I don't see a reason to prefer this method to a simpler obfuscation.
Encrypt them with an asymmetric algorithm. This kind of encryption is a big step in complexity and security and it'll be (very) useful only if license token is provided by a server/external entity. In this case it'll obfuscate license signed with its private key. Client application will validate signature with its public key and even if cracker will find this file (and decompile your code to read public key) they still won't be able to change it because they don't have private key.
Please note that data obfuscation/encryption can be used in conjunction with above mentioned steganography (for example to hide encrypted license file inside an image).
Code Obfuscation
If you're not using license signing with asymmetric encryption then last step is to obfuscate your code. Whatever you will do they'll be able to see your code, check your algorithm and workaround it. So sad, you're deploying instructions manual! Obfuscate with an Obfuscator if you want but what I strongly suggest is to move your license check in a less obvious place.
Put all your license related code in a separate DLL. Sign it (be aware that signed assemblies may be decompiled and recompiled to remove signing, there are even tools to do it almost automatically).
Pack it inside your executable resources (with a not so obvious name) and do not deploy DLL.
Handle event AppDomain.AssemblyResolve, when your DLL will be needed at run-time you'll unpack in memory and return its stream of bytes. See more about this technique in this Jeffrey Richter's post.
I like this method because they'll see there is a license check but...they won't find license code. Of course any good cracker will solve this issue in 10 minutes but you'll be (little bit more) safe from random ones.
Conclusions
To summarize a little bit this is a list of what you may do to provide a stronger license check (you can skip one or more steps, of course, but this will reduce safety):
Split your license check code in two assemblies (one to perform the check and manage license and the other to provide a public interface to that engine).
Strong sign all your assemblies.
Embed your License Engine assembly inside your License Interface assembly (see Code Obfuscation section).
Create a License server that will manage your licenses. Be careful to make it secure, to have secure connection and secure authentication (see Validation section).
Save license file locally in a safe location (see Where section) and encrypted with an asymmetric encryption algorithm (see Data Obfuscation section).
Sometimes validate license with your License Server (see Validation section).
Addendum: Software Protection Dongles
A small addendum about hardware keys (Software protection dongles). They're an invaluable tool to protect your software but you have to design your protection even more carefully. You can assume hardware itself is highly secure but weak points are its connection with computer and communication with your software.
Imagine to simply store your license into the key, a cracker may use an external USB (assuming your SPD is USB) to share same key with multiple computers. You should also store some hardware unique ID within the key but in this case weak point is connection (hardware can be emulated by a software driver). It's a pretty easy crack and this false sense of security ("I'm using Software Protection Dongle, my software is then safe") will make your application even more vulnerable (because you risk to forget other basic protections to simplify license management).
Cost vs benefits for a poor designed protection using SPD should make you consider to use a normal USB pen drive. It costs 1 $ instead of 15/20$ (or much more) for a SPD and you have same level of protection against casual crackers. Of course it won't stop a serious cracker but also a poor designed SPD won't stop it.
A true protection (assuming you're not running on a DRM enabled device) is a dongle which can also execute your code. If you can move some basic algorithms (at least to decrypt vital - and dynamic - support files) into the key then to crack your software they will need to crack hardware. For a half-decent dongle this is a very very very hard task. More carefully you design this and more code you move into the key and more you'll be safe.
In any case you should doubt about marketing campaigns: software protection with a dongle isn't easier. It can be (much) more safe but it isn't as easy as vendors say. In my opinion plug-n-play protection cost is too high compared to its benefits (benefits = how much it'll make crackers' life harder).

Unfortunately wherever you store licence information on a client's machine it's open to abuse (because it's their machine!).
The only secure way to do this is to have your program check in with a remote service, obviously this requires a lot of overhead.
My own approach is that if customers mess with their licence key then they should expect issues and you are under no obligation to assist. I would make sure your key contains information about the machine it's running on (to prevent simply copying the key) but otherwise keep it very simple.
When researching licencing myself I found a philosophy I tend to stick by - you drive away more potential customers with convoluted and difficult licencing setups than you lose through piracy.
My suggestion would be that you reverse your logic - instead of having allowing the removal of a licence key to restart the free trial why not force them to have a licence key to unlock the full application?

If you are going to write to HKEY_CURRENT_USER you won't need Administrative rights.
on the other hand, writing to HKEY_LOCAL_MACHINE requires Administrative rights.
be sure when you open the key for writing to call it like this
RegistryKey key = Registry.CurrentUser.OpenSubKey(#"Software\YourAppPath", true);
if that doesn't work for you, there is a trick to write to the end of the executable file itself, but that's another thing.

Where to Store the Protection Trial Info for Software Protection Purpose

It might be duplicate with other questions, but I swear that I googled a lot and search at StackOverflow.com a lot, and I cannot find the answer to my question:
In a C#.Net application, where to store the protection trial info, such as Expiration Date, Number of Used Times?
I understand that, all kinds of Software Protection strategies can be cracked by a sophiscated hacker (because they can almost always get around the expiration checking step). But what I'm now going to do is just to protect it in a reasonable manner that a "common"/"advanced" user cannot screw it up.
OK, in order to proof that I have googled and searched a lot at StackOverflow.com, I'm listing all the possible strategies I got:
1. Registry Entry
First, some users might not have the access to even read the Registry table.
Second, if we put the Protection Trial Info in a Registry Entry, the user can always find it out where it is by comparing the differences before and after the software installation. They can just simply change it.
OK, you might say that we should encrypt the Protection Trial Info, yes we can do that. But what if the user just change their system date before installing?
OK, you might say that we should also put a last-used date, if something is wrong, the last-used date could work as a protection guide. But what if the user just uninstall the software and delete all Registry Entries related to this software, and then reinstall the software?
I have no idea on how to deal with this. Please help.
A Plain File
First, there are some places to put the plain file:
2.a) a simple XML file under software installation path
2.b) configuration file
Again, the user can just uninstall the software and remove these plain file(s), and reinstall the software.
- The Software Itself
If we put the protection trial info (Expiration Date, we cannot put Number of Used Times) in the software itself, it is still susceptible to the cases I mentioned above. Furthermore, it's not even cool to do so.
- A Trial Product-Key
It works like a licensing process, that is, we put the Trial info into an RSA-signed string. However, it requires too many steps for a user to have a try of using the software (they might lose patience):
4.a) The user downloads the software;
4.b) The user sends an email to request a Trial Product-Key by providing user name (or email) or hardware info;
4.c) The server receives the request, RSA-signs it and send back to the user;
4.d) The user can now use it under the condition of (Expiration Date & Number of Used Times).
Now, the server has a record of the user's username or hardware info, so the user will be rejected to request a second trial. Is it legal to collection hardware info?
In a word, the user has to do one more extra step (request a Trial Product Key) just for having a try of using the software, which is not cool (thinking myself as a user).
NOTE: This question is not about the Licensing, instead, it's about where to store the TRIAL info. After the trial expires, the user should ask for a license (CD-Key/Product-Key). I'm going to use RSA signature (bound to User Hardware)
P.S.: My software will be targetting the China market, whose software market is different from US. Most people in China, they only buy hardware, they usually don't buy software like Micosoft Windows/Office (they just use pirated copies). However, some professional software aiming to a specific field, research people are still willing to buy it IF there is no crack version or the crack version is very difficult to install.

Either option 1 (plain registry key) or 2 (plain file) is just fine. Here's my reasoning:
Standard-privileged users do have read permissions for the registry. If they can't read your key, something else is wrong. Standard-privileged users do not have write permissions for the registry, but this doesn't matter because they also don't have permissions to install software in the first place. In other words, either the user will have permission to create your registry key at install time, or they'll need help installing anyway. Therefore the basic technical issues you raised for the registry key aren't really a factor.
Just don't worry about those users who do things like set back their system clock or manually hack the registry to break your key. Let me say that again: Just don't worry about users who make a conscious decision to alter their system in a significant way to get past your trial limitations — and make no mistake, setting back the system clock or editing the registry are significant modifications. The reason you shouldn't worry about these users is that they represent exactly $0 in potential income. A user willing to make to take this kind of conscious choice about pirating your software isn't going to just give up and decide to pay for your product if it doesn't work. If they can't get your software for free, they'll either go with a competitor or do without. You're in this to make money - you don't want to spend time and resources trying to grab sales you can't win or sending users to a competitor. Therefore, the basic security issues you raised for either option aren't a factor.

You won't find a single perfect solution. The efforts you put into this should be proportional to the price of the product you make. If it's worth a lot, then buy a professional solution. If not, then use any combination of methods that you find. Use the registry, request an online trial key, check if the user manipulates the system time, and so on.

I would suggest taking a slightly different tact.
Give a "lite" version of your software away. No trial, just really limited functionality.
If they want to trial a "professional" version then ask them to get a trial key. This should be encrypted in some format, store it where ever you want. When the app starts, test for the existence of this trial key. If it's there then decrypt it. Inside the key should be the expiration date of the software.
Test the date and act accordingly. If it doesn't exist then just run as the lite version.
To get a trial key, you can have them enter an email address and some other info you want into a box in your app. It's not unreasonable to ask that the machine be connected to the internet for this limited part. Even MS Office requires you to connect to the internet briefly to validate the keys. Have the app contact your server with the key request. Email them back the key.
For bonus points tie the trial key to some metric of the machine itself. Even if it's just the name of the box. Those change rarely and it's a trial anyway.
If you truly can't force them to be connected to the internet to acquire a key, then you can go a slightly different route. Have the app generate a request (which includes the machine name or something along those lines). Have the user either call you with that generated request id or have them plug it into a website. Then email them the key for that machine.
All of this prevents sharing keys. Has a fall back in case the key location is jacked with and prevents the key from being moved to other machines. It also gives you a way of doing this in a completely disconnected manner. Even if they rip the public encryption key out of your app to decrypt the software license key, they won't have your private encryption key in order to build a new license key file.
Now, key management is only one aspect of the evil you are fighting.
The next step is that you need to obfuscate your app in such a way that they can't simply decompile it and bypass your key checks. This is much more common than passing around key files.
You might even have multiple methods in the app that test for the key in different ways.. But this is a different question.
As a final bonus for those vindictive enough to do this: Seed the various pirate boards with key gen software that does interesting things to the machines of the people who are trying to rip you off. You can get really creative here.
Or, like Joel said, you could just simply not worry about them. After all, if they are going out of their way to find a cracked version of your software they weren't going to pay for it anyway and you really haven't lost anything.

Can you require that users using the trial be connected to the internet? If so just have the trial version contact a server during startup and you can check all sorts of things. you don't have to worry about storing stuff on the users computer or them tampering with the data or the system time.

I know this is an old thread, but I just stumbled upon it and other might find this useful.
A valid option these days could be that your application queries a rest service at install time to generate a trial or payed license. Every time the user opens the application the application queries the rest service for the license info that is linked to that one specific copy of software.

Implementing License Validation with RSA

I am about to sell a program I have written in C# and I want to control licenses for it, strictly. That means I want to let the client connect to my server every single time it starts. This also gives me the ability to disable keys (in case of chargebacks on paypal or distribution of the code). Of course this might be a hassle for other users, but it is necessary in this case.
Since I was unable to find any good .NET Licensing systems that are uncracked, I wanted to take the approach of writing a little one myself.
My plan was to do the following:
Generate a key.dat containing 1024 characters that gets shipped with the software (individual to each user)
In the application entrypoint add a httprequest to my server that sends the key.dat + current timestamp, encrypted.
My HTTP server (running PHP) decrypts the request and checks if the key is valid (in my database) and replies with the "access level" (license type). If the key is invalid or disabled it replies with an errorcode. Just like with the request, the reply is being salted with a timestamp, so someone can't validate his program by sending a valid packet to himself. The timestamp is being checked in the client. The reply is encrypted with RSA and a previously generated public key.
Client receives response, decrypts with private key and reacts.
Is RSA the correct approach for this, so I can assure that the packets are sent by me and are not crafted (by noone else having the public key)?
Is there a better approach for solving this problem?

Someone who wants your software bad enough will just decompile it and remove the part of the code that phones home on startup.
If you were to add a checksum to the app that checks whether the code has been altered, someone can just change the checksum the program checks against (or remove the check entirely).
People who want your application enough will find ways around any type of protection you can conceive. You're better off sticking to something simple, having a product that is worth paying for (and easily) and make sure it's worth the price you're asking.
EDIT
Given that protection is important, the fact that the users will have code running on their machines is a risk you can avoid. If the users don't have the code, they can't crack it. They can't copy it and share it.
Now, it might not apply to the application you intend to write, but you should consider writing a web, Flash or Silverlight application instead of a regular client application. That way you don't have to distribute the code to customers. All you have to do is manage credentials into the application, which should be a lot easier than your round-about RSA system.
It's also easier to push out new versions of the software in a centralized model, and you won't have to worry about theft at all. Of course, load will become an issue when it wasn't before. And not all applications can be centralized easily (or at all). I'm just proposing this to make sure you consider it because it is a valid solution to your problem.
A web-based application will have the same issues as your application (i.e. it will be down whenever the user is offline, whenever the network is down, whenever your server is down, etc). So there's no added risk in that regard.

Is RSA the correct approach for this?
I do not think RSA is your best choice.
One of the capabilities of PKE (Public Key Encryption) is that it lets parties talk to each other who previously have never exchanged information before (eg. strangers).
I do not see this applying to your case. Your software knows your server well. They are not "strangers".
Consider instead Shared Secret Key encryption, where each copy of the software you distribute is given a unique secret key, and your server knows each user's secret key as well. The keys are never sent, and must be protected, but can still be used to encrypt, sign, and validate communications.
Edit After considering the comments and other answers.
Anyone who wants your software badly enough will be able to bypass the authentication completely. RSA does nothing to prevent that.
The real question is: Does breaking a single license make all licenses vulnerable/worthless. In both cases, (RSA and Secret Key), the answer is No. Just because one copy of the software got hacked and got its key exposed, or the licenses system bypassed, other copies are no more exposed. PKE and SSE seem equal in that respect to me.
Because Shared Secret Key is easier to implement, and computationally faster to execute, I think it is preferred in this case over RSA/PKE. That is not to say RSA is "wrong". It will accomplish what you are after, to the same degree that SSE will (no more, no less). But I think SSE is the smarter choice.

Storing credit card details

I have a business requirement that forces me to store a customer's full credit card details (number, name, expiry date, CVV2) for a short period of time.
Rationale: If a customer calls to order a product and their credit card is declined on the spot you are likely to lose the sale. If you take their details, thank them for the transaction and then find that the card is declined, you can phone them back and they are more likely to find another way of paying for the product. If the credit card is accepted you clear the details from the order.
I cannot change this. The existing system stores the credit card details in clear text, and in the new system I am building to replace this I am clearly not going to replicate this!
My question, then, is how I can securely store a credit card for a short period of time. I obviously want some kind of encryption, but what's the best way to do this?
Environment: C#, WinForms, SQL-Server.

Basically avoid by all means taking the responsiblity to save the CC details on your side, however I can assume you are using a thirdparty service to do your transaction such as PayPal/Verisign or whatever, most of them have API's that enables you to save CC credentials at their side, and they give you back a key that you can then use later to complete or initiate transactions, so they take care of the hard part, while all what you have to do is store this string key in your DB.

I don't believe it's actually illegal to store CVV info (in the sense that it's against any law), but it does violate Payment Card Industry rules, and they could impose any number of different sanctions. So, your requirements could actually result in you not being able to accept credit cards ;-(

Andrew, you need to understand the PCI-DSS, no small task. Personally, I find it extremely vague but here is what I understand.
First off, from the scenario you describe I would attempt to authorize the card for the full amount and then if that failed I would store the customer's information (but not the cardholder data) so someone could contact the user. Where I use to work some of our customers would only charge $1.00 and then void the transaction immediately, just to make sure the card was valid. They would then process all orders manually.
Where you will need to store the number is on a successful authorization. The only number you need then is the credit card number and the transaction code (at least with every gateway I have ever worked with).
The standard, last time I looked at it, is not specific on encryption algorithms but instead makes it clear it should be currently unbreakable encryption.
Now, one thing you cannot do is store the CCV subsequent to authorization. My understanding is that you can store it prior to authorization but I could never get anyone that would put that in writing. Basically, you authorize the card, you better wipe it.
And it is not illegal at this point but if you get nailed they will bring the hammer down on you. They have within their authority to level heavy fines against you, but it seems like what they usually do is put you in remediation. If you don't comply I don't know what happens because everyone I have heard this happening to complied. But then they really go up your booty with a microscope.
Ultimately, I believe their only stick they really have is to prevent you from accepting credit cards. Most merchants I have worked with were scared to death of exactly that.

If you just want to store the string for a short period of time in memory, you can take a look at System.Security.SecureString.
Taken from this answer:
SecureString values are stored encrypted (obfuscated, rather), but most importantly, they are never swapped to disk and can be disposed of immediately when you're done with them.
They're tricky to use because you can only build them one character at a time (to encourage you to build them by capturing keystrokes as the user types their password), and require three lines of code to recover and then wipe their plain text, but when used properly they can make a program more secure by avoiding the virtual-memory vulnerability.
At the end of the example the SecureString is converted into a regular managed string, which makes it vulnerable again (be sure to use the try-catch-finally pattern to Zero the string after you're done with it). SecureString's use is in reducing the surface-area of attack by limiting the number of copies the Garbage Collector will make of the value, and reducing the likelihood of being written to the swap file.
// Make a SecureString
SecureString sPassphrase = new SecureString();
Console.WriteLine("Please enter your passphrase");
ConsoleKeyInfo input = Console.ReadKey(true);
while (input.Key != ConsoleKey.Enter)
{
sPassphrase.AppendChar(input.KeyChar);
Console.Write('*');
input = Console.ReadKey(true);
}
sPassphrase.MakeReadOnly();
// Recover plaintext from a SecureString
// Marshal is in the System.Runtime.InteropServices namespace
try {
IntPtr ptrPassphrase = Marshal.SecureStringToBSTR(sPassphrase);
string uPassphrase = Marshal.PtrToStringUni(ptrPassphrase);
// ... use the string ...
}
catch {
// error handling
}
finally {
Marshal.ZeroFreeBSTR(ptrPassphrase);
}

If you are going to store credit card information you really need to be PCI compliant or you're just asking for trouble.
Having said that look at the cell level encryption available in SQL Server 2005 and above. Coincidentally :) I have recently given a presentation with T-SQL samples on encryption with SQL Server 2005/2008 available here: http://moss.bennettadelson.com/Lists/Events/Attachments/9/June2008.zip (Link location updated December 23, 2008)

Agreed that you should avoid storing the data if you can. But maybe you are that third party? If so, get familiar with PCI standards. Look around a bit on the site and you'll find the security measures you are required to implement.

It costs somewhere in the neighborhood of $30,000 to become properly compliant and to be able to do that kind of stuff. You are better off using a 3rd party payment service. Personally, I recommend Element Express, and they have a "Hosted" solution that bypasses the PCI-DSS PAPDB compliance. I've had to convert to this for my own applications, even a Point of Sale machine!!! It's a big pain, but we're a small company.
http://www.elementps.com/software-providers/our-security-edge/hosted-payments/PA-DSS-Certification-vs-Elements-Hosted-Payments/
The above link has some good information about the costs associated with becoming compliant. We have had customers ask us to store credit card numbers, and we won't do it because we could be fined as well. Not good. Don't open yourself up to liability.
Edit:
Additionally, if you DO decide to store the credit card information you definitely need to consider the forms of encryption you are going to use. Symmetric ? Asymmetric ?
If you do Symmetric encryption (Passkey) then you open yourself up to some serious security vulnerabilities if the server(site) that has the key (needed to encrypt) is compromised in any way. Remember, even compiled code won't hide a text key.
If you use Asymmetric encryption (public/private keypairs) then you run into some additional issues, but if the primary public facing server is compromised they will only have the public key, and if they also access your database.. they won't be able to decrpyt the contents.
The question then is, where do you store the private key ? Do you have someone paste it in from their local computers when running admin functions.. have a separate application that runs on the desktop to view orders, etc.
There are a lot of things to take into consideration.
Final note: Use a payment gateway (Element Express, Authorize.NET, Paypal, etc.) and don't store any credit card info locally. :P
Here is a link about using X509 Asymmetric Encryption in C#: http://www.csharpbydesign.com/2008/04/asymmetric-key-encryption-with.html

Lets look at the requirement a little differently. Currently it looks like this:
As a product owner for website X i want the system to temporarily store a customers cc details so that i can recover a sale that was declined by the CC company
Ppl tend to think like that and request features in that manner. Now i think your requirement is more conveniently described as follows:
As a user i want website X to be able to retry payment for my purchase so i dont have the hassle of having to go thru the checkout process again coz that is a real pain in the...
So there's no explicit requirement for storing anything (on your side) is there? Its only implied
Payment providers can provide programmatic APIs to your merchant account and the ability to attempt a re-auth on a declined attempt. i think #bashmohandes eluded to this earlier
Not all payment providers can do this however i think its dependent on their relationships with the banks involved. Thats the stuff you want to avoid ie. having a close relationship with banks.
Scenario 1: Assuming all i said is true
You don't have to store anything but a reference to the authorization attempt. Some payment providers even give you a sweet backoffice tool so you dont have to make your own to do re-auths. I think paygate does this
Your best bet i believe is to interview a number of payment providers. they should know this stuff like the back of their hands. This is potentially a zero-code solution
Scenario 2: Assuming i'm like totally wrong but legally this storing CC stuff is ok
So you have to store that data somewhere temporarily. I advise:
use a 2-way encryption method (naturally) that is non-vendor specific so you can use any language/platform to encrypt/decrypt
decouple the encrypt/decrypt service from your app and treat it like a black box
use public/private keys for authentication to this service
put this machine on a private network with its own elevated firewall rules (doesn't have to be a hardware firewall but hardware is better)
have your app servers communicate with this machine via ssl (you could get away with a self-signed cert since its on your private LAN)
All i've suggested in scenario 2 is hurdles but eventually persistence wins the race to get to your data. The only way to absolutely secure data is to unplug your server from the ether but that option is a little radical :-)
Scenario 1 would be nice. Wouldn't it?

Consider your t logs!
If you explain to your customer the full impact (and remedial requirements if they are found out of compliance) then trust me, your 'business requirements' will change very quickly.
If you must store the credit card number (and I advance the thought here that there is no reasonable scenario where you should) and you intend to use a native encryption built-in to your database, then consider this: what about your transaction logs?
If your transaction logs could reflect a credit card number in the clear, then you are out of compliance and should budget for a $10,000 to $50,000 forensic audit at your site if you get caught. Budget for your own attorney in case your customer sues you because you should have known all this stuff.
So if you are going to store a credit card number, run the cipher in code so the transaction logs (insert or update) reflect a ciphered string, not the card number in the clear.
And don't even have a field or column in your database for CVV - encrypted or not - that forensic audit will reveal this (so will the logs) and then your customer is in BIG, BIG trouble. They will pay a fine and could lose their ability to accept credit cards. Your attorney will be very happy.

I have a blog post that deals with this exact situation of storing sensitive data in the database. The blog post uses a String Encryptor class that I built using a Triple DES algorithm but you can plug in your own if you would like.
The blog post contains the video and source code that was used. You can check it out at http://www.wrightin.gs/2008/11/how-to-encryptdecrypt-sensitive-column-contents-in-nhibernateactive-record-video.html. I think it will definitely solve your issue.