Disassembling C#

Question

I've got a question regarding C#.

I am currently working on a medical software product, and one of the important things is to make sure that the patient's data is encrypted. I got two questions regarding this:

1.) How secure is the Microsoft .NET implementation of AES (Rijndael) from System.Security.Cryptography? Does it have any known security flaws, or am I fine just using the MS implementation? (note, I know the basic background of how these algorithms work, but I am not really that deep into it to get an idea of how it works).

2.) Since the data is stored on the same PC as the application, how hard is it to get information from a C# application? Assuming I have somewhere in the code

string encrypPassword = "ThisIsMyPassword";
string encryptedString = EncryptString(ClearString, encrypPassword);
// save encryptedString to harddrive

I know that an attacker could just go down to the assemble code, and at that point there is nothing at all I can do against this (the system has to be able to encrypt / decrypt the data), but is there like a shortcut for C# to get the encrypPassword, since it is managed, or does something like this still require you to go down to the assemble code?

possible duplicate of [How to safely store encryption key in a .NET assembly](http://stackoverflow.com/questions/2528405/how-to-safely-store-encryption-key-in-a-net-assembly) — Rawling, Oct 22 '12 at 10:58
You may take a look at DPAPI, see for example: http://stackoverflow.com/q/5620028/60761 — H H, Oct 22 '12 at 11:15
@HenkHolterman, would it be valid to derive some entropy from a hash of the assembly code itself? — Jodrell, Oct 22 '12 at 11:47
@Jodrell - I don't see how that could help. Maybe as a Seed or IV but certainly not for the Key. — H H, Oct 22 '12 at 14:15

Codo · Accepted Answer · 2012-10-22T11:27:33.213

If you have a fixed password compiled into your app, then you don't need to care about the security of AES and known security faults because your data is simply not secure. A sufficiently knowledgable person with access to the PC will be able to decrypt all the data.

And locating a fixed password usually doesn't require any programming knowledge. A good hex editor will do in most case. You don't even need to know what programming language was used.

If your data is used by a single user, then you can tie the password for the patient data to his or her Windows password (or account). Windows provides some specific functions for that. See http://msdn.microsoft.com/en-us/library/aa302402.aspx for how to access it from .NET.

If you want to try it yourself, go use ILDASM or reflector (both free) to find your key. You'll find it is trivial to get it out of the binary. — Eric Fleischman, Oct 22 '12 at 15:41

Kevin · Answer 2 · 2012-10-22T12:21:14.410

In answer to the first part of your original question - the native Windows implementation of AES is NIST certified to be FIPS 140-2 compliant. Access to the certified implementation is limited to:

Using the Windows Crypto API
Using the CAPICOM com wrapper to the Windows Crypto API
Using the .Net AesCryptoServiceProvider class in the System.Security.Cryptography namespace (this class did not become available until .Net Framework 3.5)

That being said, the implementation in the RijndaelManaged class is the same, it just has not been thru the NIST certification process (this process is very long and very expensive).

The Aes algorithm is very secure (military grade encryption - especially the 256 bit key variant).

The biggest concern (agreeing with the posters above) is keeping your encryption password embedded in the application in plain text.

score 0 · Answer 3 · answered Oct 22 '12 at 11:27

0

To store your password data you could use SecureString class from System.Security namespace.

answered Oct 22 '12 at 11:27

Jacek

11,661
23
69
123

1

`SecureString` has some advantages, but it's rarely relevant. The OP has much bigger problems, that `SecureString` can't solve. – CodesInChaos Oct 22 '12 at 11:30
1

@Jodrell It doesn't even prevent the string from being read. It only protects against a few specific threats, such as error-dumps and swap files. – CodesInChaos Oct 22 '12 at 12:55

score 0 · Answer 4 · answered Oct 22 '12 at 11:49

Most decent obfuscators will encrypt the strings from your code before storing them in the assembly's strings section, and inject a method to decrypt them before use. These techniques have also long since been reverse engineered by disassemblers.

Realistically, there is almost no way to really safely store a string in any programming language. Someone can pretty much always either find the string, or reverse engineer your logic used to build it. The best thing you can do is stow down the attacker long enough to make it not worth their time and effort.

In your case, I would probably store the password encrypted in the app (as in, encrypt it yourself manually outside your app, and copy/paste it in). Possibly split it into parts so it isn't stored as a single string. Then put it back together and unencrypt it at runtime, then at runtime store it in a SecureString. Also invest in a good obfuscator, as it will help mask your unencryption logic (which will become the weak link in the security).

Disassembling C#

4 Answers4