Recent

Author Topic: Security Question  (Read 104277 times)

ezlage

  • Guest
Security Question
« on: July 24, 2012, 07:28:26 pm »
Hi friends!

Yesterday, using a disassembler, I got all cryptographic keys that were declared as const in my program.
This is really dangerous.

Does anyone know how to protect my cryptographic keys of a disassembler?

Thanks!

Laksen

  • Hero Member
  • *****
  • Posts: 794
    • J-Software
Re: Security Question
« Reply #1 on: July 24, 2012, 10:31:16 pm »
There's no simple way to do that kind of "security". You could obfuscate it but anyone who knows how to use a debugger will be able to extract the key, or simply run the code that decrypts something.

I'm no cryptographic expert, but I believe that if you store the unencrypted data or keys in memory at some point anyone on that computer will be able to access it one way or another.

Here's an example of an obfuscation scheme(Which is not safer than storing the key in plaintext in the executable, the key will be in memory at some point. Simply open the exe in IDA and put a breakpoint when calling recreatekey and a reverse engineer will have the key..)
Code: [Select]
function RecreateKey(a,b,c,d: longword): string;
var i: longint;
begin
   result := '';

   for i := 1 to 10 do
   begin
      result := chr(((a and 3) or
                    ((b and 3) shl 2) or
                    ((c and 3) shl 4) or
                    ((d and 3) shl 6))-2) + result;

      a := (a shr 2);
      b := (b shr 2);
      c := (c shr 2);
      d := (d shr 2);
   end;
end;
...
   writeln(RecreateKey(748623,349216,982011,349524));

If you really need that level of security the only way to do it is to either use another way of serving the encrypted data, create a rootkit(not adviced if you like happy customers), or hire a bunch of lawyers who are good at writing cease and desist letters :)

Leledumbo

  • Hero Member
  • *****
  • Posts: 8786
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: Security Question
« Reply #2 on: July 25, 2012, 12:04:50 am »
If you store it as string, it will be readable throught some mechanism like debugger. Laksen solution is quite safe IMO, at least without debugging symbols, one must try harder to figure it out.

avra

  • Hero Member
  • *****
  • Posts: 2533
    • Additional info
Re: Security Question
« Reply #3 on: July 25, 2012, 10:45:46 am »
If I remember well TStrHolder component has Strings property where you can store all your cryptographic keys and KeyString property which uses XOR for encrypting/decrypting them. You might try to exploit this simple idea, but as already mentioned, there will be a moment when all strings are in memory fully decrypted.
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

KpjComp

  • Hero Member
  • *****
  • Posts: 680
Re: Security Question
« Reply #4 on: July 25, 2012, 11:42:19 am »
I think any security to protect EXE's can always be cracked, but like any security measure what your really interested in is making is more difficult.

@Laksen idea is definably the first step, as without it a simple Hex Editor could potentially find the key, and you would be surprised at how many people have cracked software this way.

For Delphi I used something called IceLicence, one feature this had was Anti-Debugging, what this did was every second or so checked to see if a Debugger was attached and if so would detach is, or something like that.  This would then make it more difficult to get the key while in memory.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 12050
  • FPC developer.
Re: Security Question
« Reply #5 on: July 25, 2012, 01:22:14 pm »
If it is really important, consider a hardware encryption dongle. 

ezlage

  • Guest
Re: Security Question
« Reply #6 on: July 26, 2012, 05:34:27 pm »
Thanks all of you.
The TStrHolder and some complicated logic will be enough.

Regards.

Sorry by my poor english.

Elmug

  • Hero Member
  • *****
  • Posts: 849
Re: Security Question
« Reply #7 on: July 26, 2012, 10:50:11 pm »
I'd say that any data that needs to be secure, be in a database, and let its engine handle the password authentication.

goodname

  • Sr. Member
  • ****
  • Posts: 297
Re: Security Question
« Reply #8 on: July 27, 2012, 01:01:06 am »
I'd say that any data that needs to be secure, be in a database, and let its engine handle the password authentication.

Elmug not all programs that use encryption keys are using or have direct access to a database. I would guess that many network programs such as those using Indy, lNet, Synapse, ... are in this situation.

Once again this forum has provided an answer to something that I didn't know I should be asking about. Thank you

Elmug

  • Hero Member
  • *****
  • Posts: 849
Re: Security Question
« Reply #9 on: July 27, 2012, 03:48:03 am »
I'd say that any data that needs to be secure, be in a database, and let its engine handle the password authentication.

Elmug not all programs that use encryption keys are using or have direct access to a database. I would guess that many network programs such as those using Indy, lNet, Synapse, ... are in this situation.

Once again this forum has provided an answer to something that I didn't know I should be asking about. Thank you

Goodname,

Any Lazarus program, regardless of what it is meant for, can have a local or remote database that it accesses for data that one needs to, or is wishes to, be private and INDEPENDENT from the code.

The level of security is then determined by the database, including encryption, if necessary. No need to use encryption in the application itself, which can create the problem as mentioned in the o.p.

It is not difficult to do, and actually much business programming and applications work that way.

So it also works even for personal applications.

There are various free database engines, and using databases to store data has the benefit of being independent of a specific application, and not limited to be accessed by only one.
« Last Edit: July 27, 2012, 03:50:31 am by Elmug »

goodname

  • Sr. Member
  • ****
  • Posts: 297
Re: Security Question
« Reply #10 on: July 27, 2012, 06:23:21 am »
Goodname,

Any Lazarus program, regardless of what it is meant for, can have a local or remote database that it accesses for data that one needs to, or is wishes to, be private and INDEPENDENT from the code.

The level of security is then determined by the database, including encryption, if necessary. No need to use encryption in the application itself, which can create the problem as mentioned in the o.p.
The problem is insuring private encryption keys are known to client and server before network communication begins. So build the database to store the private encryption key. Now the database login information must be known. If your lucky the user provides this information. If not the login information must be somewhere on the client and server. Can you suggest a way to obscure this login information so that it is very difficult for someone to reverse engineer?

This can be a problem with public key encryption as well. With public encryption the decryption key must be hidden somewhere on the receiving side.

Elmug

  • Hero Member
  • *****
  • Posts: 849
Re: Security Question
« Reply #11 on: July 27, 2012, 06:50:22 am »
Goodname,

Any Lazarus program, regardless of what it is meant for, can have a local or remote database that it accesses for data that one needs to, or is wishes to, be private and INDEPENDENT from the code.

The level of security is then determined by the database, including encryption, if necessary. No need to use encryption in the application itself, which can create the problem as mentioned in the o.p.
The problem is insuring private encryption keys are known to client and server before network communication begins. So build the database to store the private encryption key. Now the database login information must be known. If your lucky the user provides this information. If not the login information must be somewhere on the client and server. Can you suggest a way to obscure this login information so that it is very difficult for someone to reverse engineer?

This can be a problem with public key encryption as well. With public encryption the decryption key must be hidden somewhere on the receiving side.

Sure, goodname.

The passwords should always be gatherered by dialog or prompt, as you say.

Otherwise, by which ever mechanism starts an application, usually a scheduler, the password is put there, and never with the code.

When a password is found in an isolated environment, with no mention as to where it applies, there, it is comparable as to if someone finds your carkeys somewhere, but there is no tag to relate it to the user or object that it opens. The password, additionally, could be in a usbstick, or for that matter, almost any where (somewhat like having a dongle).


The main thing, though, is that the main security is ensured not by obscurity, but is a "visible" or known security (that of the database itself). It is visible in the sense that a keyport is visible in our house-doors, or on older car doors. 

When we use security by obscurity, sometimes we can't even find it ourselves, which is not too publicized, but happens to be a common security problem: example many people often can not find their keys (if we hide them from others), or people forget or can't find their passwords.

For passwords, and certain other things, I have as a default text editor in my Windows 7, an editor that has the option to encrypt/decript. I never have saved, nor save the file while it is unencrypted. I also have remote backups of that encrypted file.


« Last Edit: July 27, 2012, 06:57:04 am by Elmug »

goodname

  • Sr. Member
  • ****
  • Posts: 297
Re: Security Question
« Reply #12 on: July 27, 2012, 03:40:51 pm »
Otherwise, by which ever mechanism starts an application, usually a scheduler, the password is put there, and never with the code.

When a password is found in an isolated environment, with no mention as to where it applies, there, it is comparable as to if someone finds your carkeys somewhere, but there is no tag to relate it to the user or object that it opens. The password, additionally, could be in a usbstick, or for that matter, almost any where (somewhat like having a dongle).
So your saying that the data should be in a separate file, registry, dongle, ... The separation makes it hard to associate with the program that uses it. This is security by obscurity. Just a different approach to doing the obscurity.

Knipfty

  • Full Member
  • ***
  • Posts: 232
Re: Security Question
« Reply #13 on: July 27, 2012, 03:55:17 pm »
ezlage,

Decryption keys should be part of a program, but either stored separately or entered by a user.  You want to separate the 2 pieces to make them more secure.  Of course, securing the computer physically is a must.  And running security software to prevent spyware and/or ket loggers, etc.

It's goos that you are focusing on the 1st piece, your program and that your saw the security hole you created.  But there are manyother steps in addition to this.

Personally, I would hash the encryption key and store in a separate file and hide the file path string in the application.  As long as the person you are hiding the info from doesn't have access to the computer, you have a very secur set up.
64-bit Lazarus 2.2.0 FPC 3.2.2, 64-bit Win 11

BigChimp

  • Hero Member
  • *****
  • Posts: 5740
  • Add to the wiki - it's free ;)
    • FPCUp, PaperTiger scanning and other open source projects
Re: Security Question
« Reply #14 on: July 27, 2012, 03:59:13 pm »
As Knipfty and others indicated: it's not only the encryption keys. IF you're serious about security do a threat analysis where you go through all threats and countermeasures, and decide what residual risk is acceptable.

If the risk is unacceptable, focus on measures against the highest risks and iterate.
Want quicker answers to your questions? Read http://wiki.lazarus.freepascal.org/Lazarus_Faq#What_is_the_correct_way_to_ask_questions_in_the_forum.3F

Open source including papertiger OCR/PDF scanning:
https://bitbucket.org/reiniero

Lazarus trunk+FPC trunk x86, Windows x64 unless otherwise specified

 

TinyPortal © 2005-2018