Convincing the server an app is signed properly

[Fredo]

I'm not sure if this is possible, but I have a socket server app and a
client app. I need to convince the server that the application is signed
with the same key as the server. Is there a way to do this? I'm starting to
get concerned that it's not possible.

My thinking was that maybe the server would send a random string of data to
the client. The client could then encrypt it, send it back, and the server
would either unencrypt it or encrypt its copy of the original and compare
the two. Or something along these lines, to verify it. But that would mean
they both have a key available to them.

Am I incorrect in thinking that the key used to sign an assembly isn't
stored in the assembly? Just a hash of the key is stored?

Is there some way I can get a key into the assemblies that can be used, but
that won't be easily compromised?

Any ideas on how I could do this would be greatly appreciated.

Pete

[William Stacey [MVP]]

I would not use the strong public key as it is relatively easy to replace SN
public key with another. A harder to crack (but not perfect) method is just
store the rsa xml string in a class and obfuscate your code and encrypt the
string with your obfuscator. If you expect network access at all times, you
could also use a key exchange algo like SRP and not need to save any key.
http://www.ietf.org/internet-drafts/...tls-srp-08.txt

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Fredo" <fr*****@hotmai l.com> wrote in message
news:2J******** ************@gi ganews.com...

I'm not sure if this is possible, but I have a socket server app and a
client app. I need to convince the server that the application is signed
with the same key as the server. Is there a way to do this? I'm starting to get concerned that it's not possible.

My thinking was that maybe the server would send a random string of data to the client. The client could then encrypt it, send it back, and the server
would either unencrypt it or encrypt its copy of the original and compare
the two. Or something along these lines, to verify it. But that would mean
they both have a key available to them.

Am I incorrect in thinking that the key used to sign an assembly isn't
stored in the assembly? Just a hash of the key is stored?

Is there some way I can get a key into the assemblies that can be used, but that won't be easily compromised?

Any ideas on how I could do this would be greatly appreciated.

Pete

[Fredo]

You say you can replace the SN public key with another. Could someone
extract the SN public key from one assembly and place it in another
assembly?

In other words, would the following strategy work?

Server sends unencrypted data to client. Server encrypts a local copy and
stores the encrypted copy.
Client encrypts data and sends the encrypted data back to server.
Server compares the two encrypted copies of the data. If they match, client
has proper SN key.

So, my question is, could someone else create another app and use my public
key to perform the same communication with the server?

I think you're probably right about having to go with obfuscation with
string encryption. I was hoping to avoid going that route, but I may not
have a choice.

Pete

"William Stacey [MVP]" <st***********@ mvps.org> wrote in message
news:uD******** ******@TK2MSFTN GP12.phx.gbl...

I would not use the strong public key as it is relatively easy to replace SN public key with another. A harder to crack (but not perfect) method is just store the rsa xml string in a class and obfuscate your code and encrypt the string with your obfuscator. If you expect network access at all times, you could also use a key exchange algo like SRP and not need to save any key.
http://www.ietf.org/internet-drafts/...tls-srp-08.txt

--
William Stacey, MVP
http://mvp.support.microsoft.com

[William Stacey [MVP]]

> Server sends unencrypted data to client. Server encrypts a local copy and

stores the encrypted copy.
Client encrypts data and sends the encrypted data back to server.
Server compares the two encrypted copies of the data. If they match, client has proper SN key.

Not sure what your trying to protect or do here, but I don't think the two
way conversation is required here. The client could just encrypt some data
using Rijndael and encrypt the session key using server's public key. The
server can then decrypt the Rijndael key using private key. As a public key
is public, anyone can send data to server this way if they can figure out
what is going on.

--
William Stacey, MVP
http://mvp.support.microsoft.com

[Fredo]

Okay, well, here's the full situation: I and a group of others are working
on an open source game.

Since it's open source, the code is publicly available. For reasons that are
more complex than I'd want to go in here, a freely available client would be
modifiable such that someone could create a client that makes it easy for
the user to cheat in the game.

To avoid this, we will create builds of both clients and servers that are
"certified" . It's this "certificat ion" that we're not entirely sure how to
go about at this point.

There are basically two things that need to happen.

The first is that all communications between the client and server must be
securely encrypted, as cheating could be managed by proxying the
communications and manipulating the data exchanged between clients and
servers.

The second is that the server needs to be sure that the client is the
"certified" client and not some application pretending to be the certified
client. By certified, we mean that the client is an unmodified version of
the build that we've produced.

Now, I don't want to confuse the issue. There are ways around cheating by
controlling the information that goes to the client, but for network
performance reasons, this isn't really feasible, and that's the issue that's
more complex than I'd like to go into in detail. So, let's just assume that
isn't an option, because frankly, it just isn't.

Now, if we can handle the second issue, that is, convicing the server that
the client is an unmodified version of the build we've created, then we can
easily manage the first issue.

I understand what you're saying. By very definition, the public key is
public, so any solution that relies on the public key being secure is
obviously not going to work..

I think the solution you originally offered, which is to obfuscate the build
and using string encryption to encrypt the key internally, we might be able
to make things fairly secure. We're not dealing with bank or credit data
here, so 100% security isn't essential. What's more important is simply that
security is tight enough that it's more trouble than it's worth to try to
crack the security. After all, it's just a game. But you will get the
occasional hacker who's going to make a pretty good try at cracking it, so
security has to be pretty good.

We do want to allow for an unencrypted version of the client and server to
be available so that people can test and develop extensions to the game, but
we want to be able to secure our official releases.
"William Stacey [MVP]" <st***********@ mvps.org> wrote in message
news:ee******** ******@TK2MSFTN GP11.phx.gbl...

Server sends unencrypted data to client. Server encrypts a local copy and stores the encrypted copy.
Client encrypts data and sends the encrypted data back to server.
Server compares the two encrypted copies of the data. If they match, client

has proper SN key.

Not sure what your trying to protect or do here, but I don't think the two
way conversation is required here. The client could just encrypt some

data using Rijndael and encrypt the session key using server's public key. The
server can then decrypt the Rijndael key using private key. As a public key is public, anyone can send data to server this way if they can figure out
what is going on.

--
William Stacey, MVP
http://mvp.support.microsoft.com