Encryption: can't someone use a memory viewing program to see my k

[B Maxey]

I have been working with encryption. And it seems to me that the IV and Key
are the only things you need to decrypt my data.

I can obfuscate, but my program still needs to 'call' the framework objects
in System.Security.Cryptography. And this call can be searched for. Then
using a program like SoftIce or Heapwalker they can examine the object and
its properties (namely the IV and Key). Having that they can break my
encryption.

Am I missing something?

Even if I slice and dice the key and store it all over the place, it needs
to be assembled before the framework call, right?

Thanks,

Bob

[John Davison]

B Maxey wrote:

I have been working with encryption. And it seems to me that the IV and Key
are the only things you need to decrypt my data.

I can obfuscate, but my program still needs to 'call' the framework objects
in System.Security.Cryptography. And this call can be searched for. Then
using a program like SoftIce or Heapwalker they can examine the object and
its properties (namely the IV and Key). Having that they can break my
encryption.

Am I missing something?

Even if I slice and dice the key and store it all over the place, it needs
to be assembled before the framework call, right?

Thanks,

Bob

You don't want to store the key any longer than you have to. Ask the
user for the key (by typing it in, reading a file, or whatever), use it
to encrypt/decrypt the data, then quickly erase it from memory.

It would utterly defeat the purpose of symmetric encryption to store the
key somewhere in the file. You might look into assymetric encryption
for that, but then again, I'm not too sure what you are trying to do.

John

[Steven Cheng[MSFT]]

Hi Bob,

Welcome to MSDN newsgroup.
As for the question about encryption info in assembly file you mentioned, I
think you're right. The KEY /IV pair is used for the symmetric encryption
algorithm. If both of them are stored in your application's executable file
or assemly only, it is surely possible that some cracker will decrypte your
key info from your assembly or executable. So generally we'll separate the
keyinfo from our encryption program , for example, store in registry key or
database which can be protected by Access control or authentication. In
addition, in some network tranfering scenario, the key/iv pair for
symmetric entryption are all dynamically generated at runtime and will
expire after a certain period ( such as the SSL ).

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[John Davison]

Steven Cheng[MSFT] wrote:

If both of them are stored in your application's executable file
or assemly only, it is surely possible that some cracker will decrypte your
key info from your assembly or executable. So generally we'll separate the
keyinfo from our encryption program , for example, store in registry key or
database which can be protected by Access control or authentication.

I'm not sure what the point of this would be. The program will still
need to read the key, be it from the assembly, registry or database. If
credentials are required without user intervention, those credentials
will still need to be stored somewhere, which defeats the purpose. If
user intervention is required, then why not just ask for the password to
decrypt the key?

If the point of the encryption is to prevent the user of the software
from accessing files distributed with the application, then the original
poster needs to say so and realize the futility of it.

John

[B Maxey]

I'm trying to think of some way to provide some level of copy protection
without paying $3 per license. My software cost will be more like expensive
shareware and the expensive copy protection is beyond my budget.

I asked becuse I feared the answers you guys are giving me.

So, now I am thinking more of the hashcode approach.

Thanks,

Bob

"John Davison" wrote:

Steven Cheng[MSFT] wrote:

If both of them are stored in your application's executable file
or assemly only, it is surely possible that some cracker will decrypte your
key info from your assembly or executable. So generally we'll separate the
keyinfo from our encryption program , for example, store in registry key or
database which can be protected by Access control or authentication.

I'm not sure what the point of this would be. The program will still
need to read the key, be it from the assembly, registry or database. If
credentials are required without user intervention, those credentials
will still need to be stored somewhere, which defeats the purpose. If
user intervention is required, then why not just ask for the password to
decrypt the key?

If the point of the encryption is to prevent the user of the software
from accessing files distributed with the application, then the original
poster needs to say so and realize the futility of it.

John

[John Davison]

B Maxey wrote:

I'm trying to think of some way to provide some level of copy protection
without paying $3 per license. My software cost will be more like expensive
shareware and the expensive copy protection is beyond my budget.

I asked becuse I feared the answers you guys are giving me.

So, now I am thinking more of the hashcode approach.

Thanks,

Bob

"John Davison" wrote:

Steven Cheng[MSFT] wrote:

If both of them are stored in your application's executable file
or assemly only, it is surely possible that some cracker will decrypte your
key info from your assembly or executable. So generally we'll separate the
keyinfo from our encryption program , for example, store in registry key or
database which can be protected by Access control or authentication.

I'm not sure what the point of this would be. The program will still
need to read the key, be it from the assembly, registry or database. If
credentials are required without user intervention, those credentials
will still need to be stored somewhere, which defeats the purpose. If
user intervention is required, then why not just ask for the password to
decrypt the key?

If the point of the encryption is to prevent the user of the software
from accessing files distributed with the application, then the original
poster needs to say so and realize the futility of it.

John

Bob,

There is no such thing as true copy protection.

John

[B Maxey]

And I thought the news about Santa Clause was the last traumatic event of my
life!!

"John Davison" wrote:

B Maxey wrote:

I'm trying to think of some way to provide some level of copy protection
without paying $3 per license. My software cost will be more like expensive
shareware and the expensive copy protection is beyond my budget.

I asked becuse I feared the answers you guys are giving me.

So, now I am thinking more of the hashcode approach.

Thanks,

Bob

"John Davison" wrote:

Steven Cheng[MSFT] wrote:
If both of them are stored in your application's executable file
or assemly only, it is surely possible that some cracker will decrypte your
key info from your assembly or executable. So generally we'll separate the
keyinfo from our encryption program , for example, store in registry key or
database which can be protected by Access control or authentication.

I'm not sure what the point of this would be. The program will still
need to read the key, be it from the assembly, registry or database. If
credentials are required without user intervention, those credentials
will still need to be stored somewhere, which defeats the purpose. If
user intervention is required, then why not just ask for the password to
decrypt the key?

If the point of the encryption is to prevent the user of the software
from accessing files distributed with the application, then the original
poster needs to say so and realize the futility of it.

John

Bob,

There is no such thing as true copy protection.

John

[Steven Cheng[MSFT]]

Hi Bob,

Thanks for the followup.
Don't be too worry, since there is actually no 100% secured
system/application, what we need to do is just providing security
protection as much as possible. If anyone keep interesting in your program,
there is no perfect means to prevent them as long as our application is
deployed at clientside. How do you think so?

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)