EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Public key confusion

Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.
#2287
Posted: 02/13/2007 13:34:47
by Matthew Jones (Standard support level)
Joined: 02/06/2007
Posts: 26

Quote
Innokentiy Ivanov wrote:
But if a message can be decrypted with a public key (known to everyone), what are the benefits of encryption?

My app knows that the data is valid. Simple as that. It can't have been changed since no one else can generate it. I think that signing is probably the way forward for me. The demo I've built is complete, and demonstrates all the encryption concepts nicely, but unfortunately for me it doesn't do what I need! 8-)

I now have to work out how to do the signing issue.

Presumably I can use signing to sign an assymetric encrypted data block. That will solve my purpose I guess. I have had a look at the message code, but find it hard to work out what it all means. Hence me wanting more demonstration material and more explanation of things. Sample code is what I need, which shows real world examples of how to make things happen. I guess you may get two demos out of this. 8-)

Matthew
#2288
Posted: 02/13/2007 14:05:19
by Matthew Jones (Standard support level)
Joined: 02/06/2007
Posts: 26

I've read the wikipedia info on public key encryption, and I am looking at it the wrong way round. Signing, in some form, is what I need. Be prepared for more questions. 8-)

Matthew
#2289
Posted: 02/13/2007 14:10:31
by Ken Ivanov (EldoS Corp.)

Quote
Now, it seems to me that there is a big chunk of functionality missing if I can't encrypt myself and send it to the world.

And *who* is 'the world'? If the world == everyone, then you do not need to encrypt the message at all (as everyone can decrypt it). If the world <> everyone, then you can create some key, send it to all the potential recipients and encrypt the message using this shared key before sending.

Quote
Maybe I'm just wrong in expecting to be able to encrypt and send, but if so how do the software protection tools do it? They use a key that only I have, and the user can only decode and run, and not encode.

It depends on particular tool. Some applications apply regular one-way hash function to the registration name and then just compare the license key with the calculated value.

Quote
Or is this just RSA that has this issue? Which is the better one?

I think that first of all we should clarify the requirements for your task. Then we would be able to say if particular algorithm suits these requirements.
#2290
Posted: 02/13/2007 14:35:58
by Matthew Jones (Standard support level)
Joined: 02/06/2007
Posts: 26

Quote
Innokentiy Ivanov wrote:
I think that first of all we should clarify the requirements for your task. Then we would be able to say if particular algorithm suits these requirements.

I have to say I agree, now that I'm gaining more understanding. The key is that I want my app to be able to verify that the install code (license) information it has is from me, and me alone. So, signing is the answer obviously (now I know more about it!).

I also don't want people to be able to see what I've sent them - otherwise it may be worth hacking. So some basic encryption is needed at least.

The scheme that seems sensible therefore is this:
I generate a random key for the assymetric encryption (I'm using blowfish). I output this key to the file stream. I then use the RSA to sign this in detached mode, and save that to the file stream too. Then I encrypt my data with the blowfish, and append that to the final result. All the data is now present.

My app, at the other end, then reads the blowfish key stream, and verifies the signature. If it matches, it continues to decrypt the main data.

Now, this doesn't stop anyone at all seeing the data if they know what the file contains, but it does stop anyone changing the data and making my app think it is mine.

One enhancement would be to use a "known key" to encrypt the file key so that there's another level of decryption needed - you'd have to get that one from the app before you could decode the content at all. Is this worth doing?

I think this whole thing stands up now. Did I miss anything?

What I'd really like is some more overall reading on the topic, but that may be hard to do. Perhaps what I really need is an "if you want to do this, then this is where you should look". Except that I looked at all the demos, and frankly they scared me. I just tried the SignDetached sample. First, please ditch the "Close" at the end of the sign routine. I set up all the file locations, got an "invalid something" error, and the darn thing closed! So then I had to do it all over again. Not friendly. I also can't work out which file in the Certificates directory to actually select to make it work. Every option gives me errors. But finally, when I first looked at it, I knew it wasn't for me because I don't care about certificates. I want to generate a random key, remember that, and just use it. You may call it a certificate and store it in a fancy file format, but it's scary - particularly when you can't get it to work with the supplied certificates. This is why my demo just uploaded is able to write the keys to a .pas file so my app can have them "hard coded".

Anyway, enough rambling, I'll start implementing it.

Matthew
#2298
Posted: 02/14/2007 03:59:17
by Matthew Jones (Standard support level)
Joined: 02/06/2007
Posts: 26

Quote
Matthew Jones wrote:
The scheme that seems sensible therefore is this:
I generate a random key for the assymetric encryption (I'm using blowfish). I output this key to the file stream. I then use the RSA to sign this in detached mode, and save that to the file stream too. Then I encrypt my data with the blowfish, and append that to the final result. All the data is now present.


For the benefit of anyone else who reads this, and thinks it might be a good idea, I'm an idiot. I realised this as I walked home. This is so insecure that I can't beleive I said it. I'M SIGNING THE KEY ONLY! So, my suggestion means that I give you the key, say it is definitely from me, and then append the critical data encrypted with that key. See the flaw? All you have to do is take the same symmetric key, decode the message, change it, encrypt the message with the same key and replace my original. My app would still look at it, approve the KEY and read the false data.

I'll change it I think.

What I'm going to do is sign the encrypted message. The key, while random would be nice, might as well move to my app where I can obfuscate it a little and at least make it harder to find.

Not the world's most secure system, but good enough to stop anyone else tampering with the file.

Matthew
#2299
Posted: 02/14/2007 07:38:20
by Ken Ivanov (EldoS Corp.)

You are right. That is, you should take into account the following points:
a) sensitive data should be encrypted with a key that is accessible only to you and your customers,
b) if you need to ensure that the data has not been modified or was not generated by a third party, you should use digital signing.

Transferring encryption key along with the data is a big security lack. It's a good idea to keep decryption key on your customers' machines and use it to decrypt the data. A common practice is to encrypt the data with some symmetric key (e.g., Blowfish), and then encrypt this symmetric key using some public key algorithm (e.g., RSA). This will let you use different encryption (Blowfish) keys for each data transfer, while using the same 'main' asymmetric (RSA) key.
#2300
Posted: 02/14/2007 07:41:01
by Ken Ivanov (EldoS Corp.)

We also would like to thank you for your feedback regarding the sample applications. We will review them and try to make them more user-friendly.

Quote
I also can't work out which file in the Certificates directory to actually select to make it work.

Signing process requires a private key, i.e. you should load certificate stored either in PFX or PEM format.
#2301
Posted: 02/14/2007 09:28:29
by Matthew Jones (Standard support level)
Joined: 02/06/2007
Posts: 26

Quote
Innokentiy Ivanov wrote:
Signing process requires a private key, i.e. you should load certificate stored either in PFX or PEM format.

Are the ones in the /certificates directory supposed to work? I could never get anyone of them to work, with or without the password. Clearer instructions would be handy for this.
#2302
Posted: 02/14/2007 09:45:13
by Ken Ivanov (EldoS Corp.)

Yes (and they do for us). Please check that you are setting up all the necessary options correctly (remember to set key container type to 'X.509 certificate). Please also specify the 'password' password for cert.pfx file.
#2303
Posted: 02/14/2007 10:55:54
by Matthew Jones (Standard support level)
Joined: 02/06/2007
Posts: 26

Well, for the first time ever, it just clicked and worked first time once I knew which file and which options to choose. Thanks!
Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.

Reply

Statistics

Topic viewed 9149 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!