Re: Problems with public key decryption with RSA
From: William Stacey [MVP] (staceywREMOVE_at_mvps.org)
Date: 02/03/05
- Next message: William Stacey [MVP]: "Re: Protecting assemblies from being used outside a company/group/team"
- Previous message: Ryan: "Re: Encrypting a string using public key"
- In reply to: pike: "Re: Problems with public key decryption with RSA"
- Next in thread: pike: "Re: Problems with public key decryption with RSA"
- Reply: pike: "Re: Problems with public key decryption with RSA"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 3 Feb 2005 12:21:54 -0500
hmmm... Don't ask for much? :-)
Lets see, you want to secure some data payload to any client that has never
negotiated a shared secret and the customer does not want any keys stored on
the client. Did I get that right?
I can't think of a secure way to do that. You either need to store a shared
secret on the client side EXE (not good) or negotiate some secret. If the
client could a least make a request via email or "on-line" then we could
work something out, but sending data to some anonymous client - not sure.
PKI would not work, at the client would at least need a private key and the
server would need to know the client's public key. Shared secrets can not
work, as you don't want client to talk to server or make a request. I am at
a loss. The only way I can think of is to hard code some shared secret
which is not good for obvious reasons. Maybe someone else has an idea?
PS. Maybe if when the client gets the package that kicks off a "talk" with
the server, then the client could exchange the key that the server used to
encrypt the package. That would require some more thinking, but at some
point the client needs to talk to the server (via soap msg/xml msg (or
other) in email or on-line, etc.)
-- William Stacey, MVP http://mvp.support.microsoft.com "pike" <pike@discussions.microsoft.com> wrote in message news:C4A052E8-2A33-4CBD-9822-9D9C104F75DE@microsoft.com... > Hi William > > Thanks for that explanation, a very comprehensive answer! > > My required solution does not quite fit this unfortunately, as the data > "packages" encrypted on the server may have been prepared days or weeks > before the receiving client(s) have even been set up. Therefore using Private > keys on the Clients would be undesirable (and also the customer does not want > this either). Also the package may arrive at the client via an email or CD so > there cannot be an online 'key exchange'. Would this change your solution any? > > Thanks in advance. > > Regards, > Pike > :-) > > "William Stacey [MVP]" wrote: > > > > My final solution is, for encrypting :- > > > Encrypt the data symmetrically with random key > > > Encrypt the key / IV with fixed (pre-loaded) key > > > Package as byte array > > > Digitally sign hash (with Private key) on package and send to receiver > > > > The "pre-loaded" key should be the public key of the server in your signed > > assembly and/or embedded in your code. Also above you would have an issue > > with securing the "Private key" at the clients. So a better solution may > > become: > > 1) Generate random symmetric key and iv. > > 2) Encrypt key / IV with public RSA key of server. > > 3) Encrypt data with symmetric key. > > 4) Sign hash and sign data elements with HMAC-SHA1 using symmetric key. > > Note we use the HMAC-SHA1 to sign as we don't have a RSA private key. We > > could however create one dynamically for the session and encrypt our public > > xml string in the request using RSA public key of server. However, as we > > need the new RSA key only for signing the request, we can avoid that and > > just use a keyed hash like HMAC-SHA1. You could also encrypt the resulting > > signature using the server's public RSA key - but don't think that is > > required. > > > > 5) Server decrypts key / IV with it's private key. > > 6) Server verifies hash with HMAC-SHA1 using the key. > > 7) Server decrypts data with key / iv. > > 8) Server generates reply. > > 9) Server encrypts data with key / iv. > > 10) Server signs data elements with RSA private key. > > > > 11) Client verifies signature using RSA public key. > > 12) Client decrypts data and uses. > > > > This does not require any prior stored private key on client's - only during > > the session. This follows the SSL pattern where key exchange is done using > > RSA pki first and after that symmetric encryption is used. You could also > > modify to allow server to contribute to the entropy of the shared key, but > > that would require a request/reply pair before you could use symmetric > > encryption and I am not sure how much value that would as with above model > > you still can get the shared key unless you brute force pki to discover it > > using all combinations keys. For that reason, I would keep your shared key > > as large as possible - say 64-100 bytes. Then both sides will use the sha1 > > hash of the 64 bytes or just the first 16-32 bytes for your AES crypto. You > > may also want to include a Timestamp and/or msg ID on the requests to help > > prevent reply attacks. Cheers! > > > > -- > > William > > > >
- Next message: William Stacey [MVP]: "Re: Protecting assemblies from being used outside a company/group/team"
- Previous message: Ryan: "Re: Encrypting a string using public key"
- In reply to: pike: "Re: Problems with public key decryption with RSA"
- Next in thread: pike: "Re: Problems with public key decryption with RSA"
- Reply: pike: "Re: Problems with public key decryption with RSA"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
