5

Is this encryption class sufficiently secure? Or can someone disassemble my binary to find the key and IV? I'm using it to decrpyt license files so it's quite important that it can't be easily broken.

internal static class Encryptor
{
  // Actual values are put here in my source
  private static readonly byte[] Key = { 0, 0, 0, 0, 0, 0, 0, 0 };
  private static readonly byte[] Iv = { 0, 0, 0, 0, 0, 0, 0, 0 };

  internal static String Encrypt(string source)
  {
    var des = new DESCryptoServiceProvider();
    var enc = des.CreateEncryptor(Key, Iv);
    var b = Encoding.ASCII.GetBytes(source);
    var encId = enc.TransformFinalBlock(b, 0, b.Length);
    return Convert.ToBase64String(encId);
  }

  internal static string Decrypt(string encrypted)
  {
    var des = new DESCryptoServiceProvider();
    var dec = des.CreateDecryptor(Key, Iv);
    var b = Convert.FromBase64String(encrypted);
    var decId = dec.TransformFinalBlock(b, 0, b.Length);
    return Encoding.ASCII.GetString(decId);
  }
}

This is similar to this question and this one, but neither seem to have a clear answer (as far as I can understand - and I admit to being a complete beginner on this topic). Please advise. :)

Community
  • 1
  • 1
James
  • 7,343
  • 9
  • 46
  • 82
  • 2
    An IV should always, always, always be randomly generated and unique for each message. If you hardcode it, you are introducing huge vulnerabilities in your cipherstream. – Nick Johnson Oct 19 '11 at 00:55
  • @Nick Johnson: This is to decode a license file that will ship with the product (each license file is unique to the purchasing organisation). So I think I have to hard code it, don't I? I don't really understand how it works. – James Oct 19 '11 at 01:04
  • @James No, you need to prefix the IV to the encrypted message. If you're not familiar with the security implications of decisions like this, you should use a library that handles it for you, rather than rolling-your-own. – Nick Johnson Oct 19 '11 at 01:25

3 Answers3

8

Yes, this is easily broken. Any developer with knowledge of tools such as Reflector (or ILSpy, or dotPeek, or ...), will have no trouble identifying the encryption function and finding your key. Someone who has the assembly will even be able to call Decrypt directly, not bothering with extracting the key.

Is it sufficiently secure ? It depends, only you can answer that. If this is for licensing, it is the equivalent of putting a sticker on a box saying "Don't copy my software". On the other hand, making a robust licensing scheme that is hard to break for an experienced and determined attacker, is a large undertaking, and you might want to consider if it is worth the effort. Personally, I would invest my time in making the software so awesome, that people will want to pay for it, rather than stopping a small number of bad guys from using it unlicensed.

driis
  • 161,458
  • 45
  • 265
  • 341
4

No, it's not secure. It would be easy to break, even with obfuscation. Someone can make a keygen pretty quickly.

You can solve the secret key issue by using public key encryption, so only the public part will be included in the assembly (and you keep the private key to yourself).

OTOH someone can just replace this public key with it's own... (make a patch and a keygen.) so you need a bit more to protect your code, e.g. code signing would help.

Creating a safe DRM is not an easy job (actually it's not possible IMO). You can invest much more time than it would take (for someone else to crack it). So you can either:

a) use a simple one to keep honest people honest;

b) create or buy (cheaper than your own) some complex solution, but not 100% safe - but that can give you some extra safe time to sell your app;

poupou
  • 43,413
  • 6
  • 77
  • 174
-1

It is trivially easy to steal the key from the compiled assembly.
You need to use asymmetric encryption (RSA).

Next, you'll ask how to prevent people from modifying the assembly to put in their own public key, or to remove the entire license check.

Dan J
  • 16,319
  • 7
  • 50
  • 82
SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964