Quantcast

Bouncy Castle versus out of the box Java security

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bouncy Castle versus out of the box Java security

Bernard Giannetti
Hi,

I want to encrypt/decrypt text-based properties files for licensing purpose for a Java application.

From what I've read (I'm very new to encryption), I would create an asymmetric key pair (private/public) using Java's keytool.
The text properties file would be encrypted using the private key
(say on a server) and the encrypted file is sent to the user.
The user would paste the file (or contents) into the application (running on their computer).
When the application executes, the file is decrypted using the public key (already in the codebase of the application) to verify the licence.

To do the encrypt/decrypt I would base code on this tutorial http://download.oracle.com/javase/tutorial/security/apisign/index.html as it seems to do the job.

What does Bouncy Castle provide which is "better" than the default Java?

I contacted the author of
license3j (which uses Bouncy Castle) and asked why Bouncy Castle was used.
He said Bouncy Castle provides a format compatible with PGP and that Java (standard) does not.
Is he suggesting standard Java is "less secure" than that provided by Bouncy Castle?

Am I open to easy keygen cracking of my private key if I simply use what Java provides as standard?


Thanks,

Bernard.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bouncy Castle versus out of the box Java security

Tomas Gustavsson-3

Hi,

There is nothing wrong per se with the standard java crypto classes. The
crypt is not broken.
The fact that you are asking this question however tells me you need the
bouncy castle classes, because you do not seem to have thorough
knowledge in the field. Nothing bad with that, it's tricky. Implementing
security and encryption correctly is hard, many people have failed.
For one thing, you never encrypt a file with asymmetric keys, you use
CMS or PGP or similar that does it properly.

The standard java APIs are very low level, forcing you to know all the
nitty gritty details of cryptography, such as paddings, key wrapping,
which algorithms are good for what etc etc.
Going directly at the task with low level APIs will most likely lead to
security vulnerabilities and poor performance.

Bouncycastle provides a number of higher level classes that makes
implementation of the things you want to do much easier. Easier for you
(and me) most likely also means more secure.

Standard java does not provide these higher level, easy to use classes.

Regards,
Tomas

On 05/16/2011 12:43 PM, Bernard Giannetti wrote:

> Hi,
>
> I want to encrypt/decrypt text-based properties files for licensing purpose for a Java application.
>
> From what I've read (I'm very new to encryption), I would create an asymmetric key pair (private/public) using Java's keytool.
> The text properties file would be encrypted using the private key (say on a server) and the encrypted file is sent to the user.
> The user would paste the file (or contents) into the application (running on their computer).
> When the application executes, the file is decrypted using the public key (already in the codebase of the application) to verify the licence.
>
> To do the encrypt/decrypt I would base code on this tutorial http://download.oracle.com/javase/tutorial/security/apisign/index.html as it seems to do the job.
>
> What does Bouncy Castle provide which is "better" than the default Java?
>
> I contacted the author of license3j (which uses Bouncy Castle) and asked why Bouncy Castle was used.
> He said Bouncy Castle provides a format compatible with PGP and that Java (standard) does not.
> Is he suggesting standard Java is "less secure" than that provided by Bouncy Castle?
>
> Am I open to easy keygen cracking of my private key if I simply use what Java provides as standard?
>  
>
> Thanks,
>
> Bernard.
>
>
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bouncy Castle versus out of the box Java security

Tomas Gustavsson-3

Hi again,

Reading your specific use case more thoroughly it seems to deal with
some sort of simple software license key verification. In this specific
case the security implications of any implementation seems negligible,
and the amount of data tiny. So in this specific case the oracle
tutorial probably is all you need.
If you plan on doing something more complex, or with higher security
requirement (higher costs in case of security breach), you should
consider alternatives.

Cheers,
Tomas

On 05/16/2011 01:25 PM, Tomas Gustavsson wrote:

>
> Hi,
>
> There is nothing wrong per se with the standard java crypto classes. The
> crypt is not broken.
> The fact that you are asking this question however tells me you need the
> bouncy castle classes, because you do not seem to have thorough
> knowledge in the field. Nothing bad with that, it's tricky. Implementing
> security and encryption correctly is hard, many people have failed.
> For one thing, you never encrypt a file with asymmetric keys, you use
> CMS or PGP or similar that does it properly.
>
> The standard java APIs are very low level, forcing you to know all the
> nitty gritty details of cryptography, such as paddings, key wrapping,
> which algorithms are good for what etc etc.
> Going directly at the task with low level APIs will most likely lead to
> security vulnerabilities and poor performance.
>
> Bouncycastle provides a number of higher level classes that makes
> implementation of the things you want to do much easier. Easier for you
> (and me) most likely also means more secure.
>
> Standard java does not provide these higher level, easy to use classes.
>
> Regards,
> Tomas
>
> On 05/16/2011 12:43 PM, Bernard Giannetti wrote:
>> Hi,
>>
>> I want to encrypt/decrypt text-based properties files for licensing purpose for a Java application.
>>
>> From what I've read (I'm very new to encryption), I would create an asymmetric key pair (private/public) using Java's keytool.
>> The text properties file would be encrypted using the private key (say on a server) and the encrypted file is sent to the user.
>> The user would paste the file (or contents) into the application (running on their computer).
>> When the application executes, the file is decrypted using the public key (already in the codebase of the application) to verify the licence.
>>
>> To do the encrypt/decrypt I would base code on this tutorial http://download.oracle.com/javase/tutorial/security/apisign/index.html as it seems to do the job.
>>
>> What does Bouncy Castle provide which is "better" than the default Java?
>>
>> I contacted the author of license3j (which uses Bouncy Castle) and asked why Bouncy Castle was used.
>> He said Bouncy Castle provides a format compatible with PGP and that Java (standard) does not.
>> Is he suggesting standard Java is "less secure" than that provided by Bouncy Castle?
>>
>> Am I open to easy keygen cracking of my private key if I simply use what Java provides as standard?
>>  
>>
>> Thanks,
>>
>> Bernard.
>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Bouncy Castle versus out of the box Java security

Bernard Giannetti
Hi Tomas,

Thanks for your quick and detailed replies!

> Reading your specific use case more thoroughly it seems to deal with
> some sort of simple software license key verification. In this specific
> case the security implications of any implementation seems negligible,
> and the amount of data tiny. So in this specific case the oracle
> tutorial probably is all you need.

Exactly - a plain text properties file, encrypted at the server and decrypted on each user's installation of my application (to verify the license).

Are you now suggesting it's okay to use (and create) asymmetric keys (for my situation), either:

    - Using Java's keytool, or
    - Programmatically as per the Oracle tutorial, or
    - Using Bouncy Castle?

Should I use standard Java to do the encryption/decryption too...or should I consider Bouncy Castle for this too?


Thanks again,

Bernard.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Bouncy Castle versus out of the box Java security

Bernard Giannetti
In reply to this post by Tomas Gustavsson-3
Hi Tomas,

Thanks for your quick and detailed replies!

> Reading your specific use case more thoroughly it seems to deal with
> some sort of simple software license key verification. In this specific
> case the security implications of any implementation seems negligible,
> and the amount of data tiny. So in this specific case the oracle
> tutorial probably is all you need.

Exactly - a plain text properties file, encrypted at the server and decrypted on each user's installation of my application (to verify the license).

Are you now suggesting it's okay to use (and create) asymmetric keys (for my situation), either:

    - Using Java's keytool, or
    - Programmatically as per the Oracle tutorial, or
    - Using Bouncy Castle?

Should I use standard Java to do the encryption/decryption too...or should I consider Bouncy Castle for this too?


Thanks again,

Bernard.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bouncy Castle versus out of the box Java security

Arshad Noor
Bernard,

While most problems for preserving secrets can be solved with some
form of cryptography, the business problem that you're trying to
solve is not so trivial.

Consider this: in order to decrypt your encrypted license file, the
user of the application must have the decryption key (symmetric or
private, depending on the type of cryptography used).  Since the goal
of licensing is to prevent unauthorized users from using your tools
(and or content), have you considered that if a malicious person had
the decryption key, they could then copy the plaintext license file
and thwart your licensing scheme from that point on?

Before solving a particular problem with cryptography, you need to
consider the threat-model and devise your solution to fit the problem.

Arshad Noor
StrongAuth, Inc.

----- Original Message -----
From: "Bernard Giannetti" <[hidden email]>
To: [hidden email]
Sent: Monday, May 16, 2011 7:40:17 AM (GMT-0800) America/Los_Angeles
Subject: RE: [dev-crypto] Bouncy Castle versus out of the box Java security


Hi Tomas,

Thanks for your quick and detailed replies!

> Reading your specific use case more thoroughly it seems to deal with
> some sort of simple software license key verification. In this specific
> case the security implications of any implementation seems negligible,
> and the amount of data tiny. So in this specific case the oracle
> tutorial probably is all you need.

Exactly - a plain text properties file, encrypted at the server and decrypted on each user's installation of my application (to verify the license).

A re you now suggesting it's okay to use (and create) asymmetric keys (for my situation), either:

- Using Java's keytool, or
- Programmatically as per the Oracle tutorial, or
- Using Bouncy Castle?

Should I use standard Java to do the encryption/decryption too...or should I consider Bouncy Castle for this too?


Thanks again,

Bernard.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bouncy Castle versus out of the box Java security

Bernard Giannetti
Hi Arshad,

> Consider this: in order to decrypt your encrypted license file, the
> user of the application must have the decryption key (symmetric or
> private, depending on the type of cryptography used). Since the goal
> of licensing is to prevent unauthorized users from using your tools
> (and or content), have you considered that if a malicious person had
> the decryption key, they could then copy the plaintext license file
> and thwart your licensing scheme from that point on?

The application will contain code to decrypt the license file and the public decryption key.
If the application code is hacked and the decryption key (and code) are extracted, all that can be done is decrypt the license file, right?

How is my licensing thwarted from this point on?

I have assumed that my application will at some point be hacked...that's life.  But I am trying to make life difficult for the casual tinkerer.

I also want to implement a scheme whereby the license is checked back with the server and (somehow) keeps a count/reference to the issued licenses.
This will hopefully minimise people simply forwarding their license.txt file to other people.

Any ideas on enforcing license control would be greatly appreciated :-)


Cheers,

Bernard.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bouncy Castle versus out of the box Java security

Arshad Noor
In reply to this post by Bernard Giannetti
Once the license file is decrypted, it can be circulated freely on
the internet to allow others to use your product/content without
the need to pay you.  The application doesn't need to be hacked for
this to happen - tools like truss will point to the plaintext
license file when decrypted by your software/key.

I am in agreement with Andreas that working on licensing schemes
is an absolute waste of time.  It is far better to spend your time
creating great software, treating your customers with respect (not
as potential thieves) and having them come back to you for the
fantastic value you provide.

We are a producer of open-source key-management tools; yet our
customers from all over the world pay us to deliver a completely
integrated EKM solution despite the fact that the entire source
code for our products is included with every "appliance" we sell.
In the short-term this might be a hard strategy to get used to;
but in the long-term it is the most competitive strategy you can
adopt.  

Good luck.

Arshad Noor
StrongAuth, Inc.

----- Original Message -----
From: "Bernard Giannetti" <[hidden email]>
To: [hidden email]
Sent: Tuesday, May 17, 2011 3:13:16 AM (GMT-0800) America/Los_Angeles
Subject: Re: [dev-crypto] Bouncy Castle versus out of the box Java security


Hi Arshad,

> Consider this: in order to decrypt your encrypted license file, the
> user of the application must have the decryption key (symmetric or
> private, depending on the type of cryptography used). Since the goal
> of licensing is to prevent unauthorized users from using your tools
> (and or content), have you considered that if a malicious person had
> the decryption key, they could then copy the plaintext license file
> and thwart your licensing scheme from that point on?

The application will contain code to decrypt the license file and the public decryption key.
If the application code is hacked and the decryption key (and code) are extracted, all that can be done is decrypt the license file, right?

How is my licensing thwarted from this point on?

I have assumed that my application will at some point be hacked...that's life. But I am trying to make life difficult for the casual tinkerer.

I also want to implement a scheme whereby the license is checked back with the server and (somehow) keeps a count/reference to the issued licenses.
This will hopefully minimise people simply forwarding their license.txt file to other people.

Any ideas on enforcing license control would be greatly appreciated :-)


Cheers,

Bernard.


Loading...