views:

42

answers:

2

I have made a small program that will allow me to send licenses in encrypted form to users.

At the moment I have

  • An RSA private key that encrypts my AES key
  • A single AES/CBC key that encrypts the data
  • An RSA public key

Both the AES and public key are hard coded onto the device.

How should I deal with the IV when a license is requested, should I create a static one on the device or send a new one with every new license I create?

+2  A: 

Isn't this proposal totally silly?

You should encrypt with RSA public keys not with a private key. If you encrypt with a private key as you propose then everyone with access to the public key will learn the AES key and will be able to decrypt or forge anything. Of course for the same reason you should also not use the same AES key for distinct receivers.

And to answer the question, you should use a new random IV for each AES/CBC encryption.

miss match
+1  A: 

If I understand what you are trying to do then, like most licensing schemes, it is basically a DRM scheme. I'll only address the cryptography problem, but there is also of course the problem of playing hide-and-seek from the hackers. You should know that no DRM scheme offers any measurable security (unless perhaps security hardware is involved) in the cryptographic sense, but they are still common and some developers are comfortable with the logic behind them.

What you want to do is generate your license data and include some information that prevents a user from simply copying a valid license file from a legitimate user. Examples might be mac address, phone number, etc. Then you sign this data. The license then consists of the unencrypted license and the signature bytes. On the user side, your installation software will verify the signature using the hard-coded public key, and perform any other checks (mac address matches, phone number matches, etc).

This would be the core of your scheme, and is enough for most developers. You can take this core and further obfuscate it using ad-hoc including encryption, splitting, etc., depending on how far you want to go with the hide-and-seek game.

EDIT:

If I may make a suggestion, I think the book Beginning Cryptography With Java would be a wise investment. It includes examples that using the Bouncycastle library. You can donwload the examples for free from the same website.

GregS
This is what I am trying to do. One more thing, you said that I should add the plain text and the Signature to the same file. How do I determine when the signature starts and ends?
jax
Your file format that contains the signature should do that for you. An standard example is PKCS7.
GregS
thanks, I will check this website out.
jax