Protecting Encryption Algorithms

[Matthew Inger]

Can anyone suggest a strategy for safeguarding an encryption
algorithm which is to be used in both java and c/c++?

Key based algorithms are desired. Here's the issues:

1. If i have to decrypt from java, i can't have the .dll/.so
not export at least the jni methods for encryption/decryption,
so someone could always view the symbol table and find those
jni routines.

2. I don't want to duplicate the code in java, as anyone with a
decompiler can get to it (even if it's obfuscated, someone could
figure it out).

3. Given that #1 is not a problem, how to safeguard the key is
another question. Do I put it in a file on disk, and let the OS
permissions protect it?

Any suggestions here would be greatly appreciated.

 

[Tom St Denis]

Can anyone suggest a strategy for safeguarding an encryption
algorithm which is to be used in both java and c/c++?

Key based algorithms are desired. Here's the issues:

1. If i have to decrypt from java, i can't have the .dll/.so
not export at least the jni methods for encryption/decryption,
so someone could always view the symbol table and find those
jni routines.

2. I don't want to duplicate the code in java, as anyone with a
decompiler can get to it (even if it's obfuscated, someone could
figure it out).

3. Given that #1 is not a problem, how to safeguard the key is
another question. Do I put it in a file on disk, and let the OS
permissions protect it?

Any suggestions here would be greatly appreciated.

Yeah, don't base your security on obscurity and if your method is that great
get a patent first.

Tom

 

[lallous]

Hello,

Your problem exists even w/ non java programs when it comes to
decrypting/encrypting information while the key is somewhere in the
application.

One solution is to use public key system where you only decrypt given only
the public key which you don't care if retrieved....

No matter how hard you try to obfuscate, the determined can reverse engineer
your application and get what he wants.


my 2c,
Elias

 

[Chris Smith]

Can anyone suggest a strategy for safeguarding an encryption
algorithm which is to be used in both java and c/c++?

Key based algorithms are desired.

The way to safeguard decryption is to do it on a machine that's not
accessible to the person trying to compromise the algorithm. That's it
-- that's the *only* way you can accomplish this. If a computer has the
ability to decrypt something without help, and if your potential
malicious party has control over that computer, it's only a matter of
time before the malicious party is able to overcome any barriers you may
put in the way.

Client-side security is doomed. If you rely on it in your software,
your software is doomed. It's as simple as that.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Sudsy]

Chris Smith wrote:

Client-side security is doomed. If you rely on it in your software,
your software is doomed. It's as simple as that.

So you don't like the idea of using a password-protected PKCS-12
keystore? Seems some fairly bright people would disagree...

 

[Tony Morris]

PKCS-12 is a public key encryption algorithm (which is asymmetric).
The problem of "client-side security" applies to symmetric encryption
algorithms.
Asymmetric encryption overcomes the problems of key distribution.

I agree that "client-side security is doomed", but PKCS-12 is not to be
considered "client-side security" in this context.

The bright people should be able to expand on this explanation.

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)

 

[Chris Smith]

Chris Smith wrote:


So you don't like the idea of using a password-protected PKCS-12
keystore? Seems some fairly bright people would disagree...

I should back off a bit from what was perhaps an overly general
statement. My interpretation of Matthew's post was that he wants to
allow his software to decrypt something, but not allow the user to
decrypt that same thing. That's a different beast entirely from the
keystore, where you don't care whether your software is involved but
only if the user can authenticate. The latter is solvable; the former
is not. Note that I listed this condition ("If your computer has the
ability to decrypt something without help..."), but probably didn't
emphasize it enough.

(Of course, in a multi-user environment with UNIX setuid binaries,
that's not entirely true. Nevertheless, given my original condition
that the hostile user has control over the machine where the software is
running, it is indeed an impossible problem.)

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Sudsy]

PKCS-12 is a public key encryption algorithm (which is asymmetric).

No, it's not.

The problem of "client-side security" applies to symmetric encryption
algorithms.

Says who?

Asymmetric encryption overcomes the problems of key distribution.

I agree that "client-side security is doomed", but PKCS-12 is not to be
considered "client-side security" in this context.

A keystore which contains private and public keys, protected by a
password, stored on the client (I prefer removable media myself)
is "not to be considered" as client-side security? According to
who?

The bright people should be able to expand on this explanation.

The bright people already know the meaning of cryptographic terms. ;-)

 

[Sudsy]

Chris Smith wrote:

I should back off a bit from what was perhaps an overly general
statement. My interpretation of Matthew's post was that he wants to
allow his software to decrypt something, but not allow the user to
decrypt that same thing. That's a different beast entirely from the
keystore, where you don't care whether your software is involved but
only if the user can authenticate. The latter is solvable; the former
is not. Note that I listed this condition ("If your computer has the
ability to decrypt something without help..."), but probably didn't
emphasize it enough.

Fair enough. I was only responding to the "impossible" claim.
The caveat did clarify things but could have been overlooked
or the implications not fully understood. Thanks.

 

[Tony Morris]

Correction, PKCS is used with asymmetric encryption algorithms.

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)