Public-Private Keys (WireShark)

Wireshark Plugin For Uru Client Protocol

Moderator: Wireshark Plugin Managers

User avatar
Nalates
Member
Posts: 437
Joined: Mon Dec 22, 2008 7:50 pm

Public-Private Keys (WireShark)

Post by Nalates »

As Open Uru advances I am wondering if the use of network packet encryption will continue and if it will serve any purpose.

Once the client side code is available, one can either see the needed key and copy it. Or if the key is removed by Cyan before release one can compile with marker code and easily find it in the current game client. Also, how does anyone compile a working client? Or at least one that will work with the Cyan shard if the key is removed?

If new shard operators do not have a copy of the corresponding Cyan key for server side then they have to create their own key and therefore their own client side software. This would seem to make it unnecessarily complicated to connect to different shards. It would seem a key management system might be needed. In all a lot of complication for what purpose?

I'm thinking once the code is released the purpose for the encryption is gone. Am I missing something?
Nalates
GoW, GoMa and GoA apprentice - Guildmaster GoC - SL = Nalates Urriah
Christian Walther
Member
Posts: 317
Joined: Sat Dec 13, 2008 10:54 am

Re: Public-Private Keys (WireShark)

Post by Christian Walther »

I have the impression you are mixing up the public and private keys. (If you are not familiar with public-key cryptography, read up on it. The specific method used in Uru is Diffie-Hellman key exchange.)

The public key is, as its name implies, public. It is part of the client already and can easily be extracted from the binary, no need for source code.

Right now it is hardcoded, but to make a client that can connect to multiple shards, it will obviously have to be made configurable. I see no problem with that, WhoM shows how to do it. It downloads the list of shards together with their public keys as an external configuration file that can be updated independently of the application. Is that a complication?

The private key is secret, it is part of the server configuration (hopefully not hardcoded), and the one currently in use on the MOULa servers will not (should not, if they behave predictably for once) be released by Cyan. Sharing private keys would defeat the purpose.

As to the question of whether encryption should be disabled – I don’t see why. Encryption is a good thing. Knowing that only I and the server operator know what I am doing on the server, and knowing that I am connected to the server that I think I am, seems like a desirable thing to me, even if not as essential in our context as, say, for banking. Why give that up once you have it? Sure, it makes debugging a little more inconvenient – but not nearly enough to justify disabling it in production use. Making a client (or server) that feeds session keys to Wireshark in real-time should be no problem (even now), and for debugging you could always make a client and server with no encryption (once you have the source).

You seem to work under the assumption that the sole purpose of the encryption is to make reverse-engineering harder. That may have been part of the motivation, but in my opinion it is not the reason that justifies it, at all. It doesn’t actually gain you a lot in that regard, only a bit of security-by-obscurity. That may deter some clueless script kiddies, but not the people who know what they are doing and are willing to invest some work (work that has already been done by now, one might add, so by that reasoning the encryption could already be disabled now). The real benefit of encryption is what I mentioned above.
User avatar
Nalates
Member
Posts: 437
Joined: Mon Dec 22, 2008 7:50 pm

Re: Public-Private Keys (WireShark)

Post by Nalates »

No - I understand the public/private key system and build it into various web sites.

That WhoM has written the handler for multiple keys is nice. That accomplishes the work.

What I'm not getting is that if the server side is public, not the key, but everything else, why would one bother to encrypt?
I keep rereading your post looking for "The real benefit of encryption is what I mentioned above." and not finding it... other than encryption is a good thing. I'm missing something.

My thinking is that if I wanted to send instructions that would indicate my AV was kicking cones into a precise stack, or that my camera had taken a picture and was sending the image information, I would look at the server code to see what it needed, then write the data pack, encrypt it using the appropriate public key, and send it. Where does the encryption ad any additional protection once all is open?

Using HTTPS to hide valuable packets among the blinding array of network traffic makes sense for logons. If Uru encryption is only protecting sign up and login I suppose it serves a purpose. But I took your posting to mean many of the game packets are encrypted. Why would one encrypt that an AV moved or opened a door? With the server code I could spoof that whether encrypted or not.
Nalates
GoW, GoMa and GoA apprentice - Guildmaster GoC - SL = Nalates Urriah
kaelisebonrai
Member
Posts: 12
Joined: Tue Dec 23, 2008 10:36 am

Re: Public-Private Keys (WireShark)

Post by kaelisebonrai »

You, uh.. just proved you didn't understand it. =)

If there is a private key, and a public key. The public key is /shared/, and the private key is kept private.

If, as Christian said... the server data does not hardcode the private key, then, why give up on encryption? The private key is /still/ private, in this case. =)

Note, however, that Uru is.. uh, not the best, when it comes to security, as it relies on "security through obscurity" which, as many will tell you... "security through obscurity is not security at all".
User avatar
Mac_Fife
Member
Posts: 1239
Joined: Fri Dec 19, 2008 12:38 am
Location: Scotland
Contact:

Re: Public-Private Keys (WireShark)

Post by Mac_Fife »

Nalates wrote:What I'm not getting is that if the server side is public, not the key, but everything else, why would one bother to encrypt?
Well consider shards that develop along divergent paths - Shard-X works with a modified Client-X, Shard-Y works with a different Client-Y. Client-X maybe allows players to create Bahro avatars, but Shard-Y doesn't like that sort of thing. While the encryption per se isn't maybe essential to validate the client-server relationship the key exchange is, so leaving the encryption in makes sense. Sure you can spoof it, but taking the view that "I know people can pick my locks, so I'll just leave my front door wide open" doesn't seem too smart. I think as we've seen from the exchanges on the MOUL forums, a lot of people get worried (rightly or wrongly) about vault integrity and the perceived security of a shard (whether real or not) may well have an influence on the success of the shard.
kaelisebonrai wrote:[...] it relies on "security through obscurity" which, as many will tell you... "security through obscurity is not security at all".
True, but I guess, when it comes down to it, all security relies on obscurity in some form or other.
Mac_Fife
OpenUru.org wiki wrangler
User avatar
Nalates
Member
Posts: 437
Joined: Mon Dec 22, 2008 7:50 pm

Re: Public-Private Keys (WireShark)

Post by Nalates »

Geez kaelisebonrai... am I not making my self clear? Quoting myself with enhancement: ...if the server side

Code: Select all

[/color] is public, [b][i][u]not the key,[/u][/i][/b] [u]but everything else[/u]... 

One can set up a secure pipeline for the information. I get that. But to what purpose? I feel safer... is nice but I don't see it as justification for spending CPU cycles when there is still no security.

Mac_Fife gets closer to answering the question by saying that it could ensure one is using the correct client with the correct server. While a key exchange can validate I'm talking to the right server, is there really any serious doubt I've connected to the right server? Or even a concern?

We do key exchanges when we are worried someone might have gone to the trouble to spoof a DNS or high jack a router. I don't see that as a real concern for an Open Uru server. 

If shards do allow Bahro AV's, say, do we really need a different client? If we do I would think there are easier ways to match up client and server. What does a user do with an error message about keys not matching? 

The only place I can see that encryption makes any difference is in logon and vault access. I don't see it accomplishing much there. I would think it much faster to let the lower network functions handle encryption with a simple https protocol than encode at the higher game level.

When one knows what's going on on both ends of a secure tube and has access to the input end... and the data is useless to any possible listener... I just don't see a reason to encrypt the majority of the game's data stream.
Nalates
GoW, GoMa and GoA apprentice - Guildmaster GoC - SL = Nalates Urriah
Christian Walther
Member
Posts: 317
Joined: Sat Dec 13, 2008 10:54 am

Re: Public-Private Keys (WireShark)

Post by Christian Walther »

Nalates wrote:I keep rereading your post looking for "The real benefit of encryption is what I mentioned above." and not finding it...
What I was referring to by “above” is
Christian Walther wrote:Knowing that only I and the server operator know what I am doing on the server, and knowing that I am connected to the server that I think I am
Nalates wrote:My thinking is that if I wanted to send instructions that would indicate my AV was kicking cones into a precise stack, or that my camera had taken a picture and was sending the image information, I would look at the server code to see what it needed, then write the data pack, encrypt it using the appropriate public key, and send it. Where does the encryption ad any additional protection once all is open?
It doesn’t. That is not the purpose of connection encryption. That falls under what Kaelis referred to as “security by obscurity” – the lack of a permissions system on the vault, the lack of input validation, etc. This is a completely orthogonal issue to whether the connection is encrypted (other than that the encryption contributes a bit of obscurity). (And there seems to be a broad consensus that it is something that needs to be addressed as soon as possible, as with fan code evolving and Cyan code being released, more and more of the obscurity is wearing off. Parts of it may have been addressed in the recent security update, I don’t know. It just has nothing to do with the encryption.)

I’m sure you are aware that the exact example of KI images you cite has been performed on MOULa, encryption or not. No knowledge of the server code is required for that, so this is not something that will change with the release of the server (binaries or source code).
Nalates wrote:But I took your posting to mean many of the game packets are encrypted.
That is correct. The connections to the gatekeeper, auth, and game servers are completely encrypted (apart from the first few packets where the key negotiation happens). The connection to the file server is not.
Mac_Five wrote:Well consider shards that develop along divergent paths - Shard-X works with a modified Client-X, Shard-Y works with a different Client-Y. Client-X maybe allows players to create Bahro avatars, but Shard-Y doesn't like that sort of thing. While the encryption per se isn't maybe essential to validate the client-server relationship the key exchange is, so leaving the encryption in makes sense.
Note, however, that this scenario is not addressed by the current system. The client is not authenticated to the server, only the other way around (as a side effect of the key exchange). Currently, any client can be used on a given shard, whether the shard operator likes it or not, as evidenced by WhoM or the Bahro players.
Nalates wrote:I feel safer... is nice but I don't see it as justification for spending CPU cycles when there is still no security. […] Is there really any serious doubt I've connected to the right server? Or even a concern?
Maybe not – but is there a reason in the other direction? The question is not if encryption should be introduced, but if the encryption we already have should be thrown out. I don’t see a cost-benefit-tradeoff here. CPU cycles? I think what you are doing here is what is known as “premature optimization”. Have you measured that the few XOR operations (and whatever else RC4 does) have any nonnegligible effect on the total CPU usage of Uru?
Nalates wrote:I would think it much faster to let the lower network functions handle encryption with a simple https protocol than encode at the higher game level.
Assuming that you mean “SSL”, not “https”, that is exactly what happens, basically (not specifically using SSL, but the same principles). The encryption sits between the TCP and game protocol layers, it’s the whole stream that is encrypted, not individual game messages.
User avatar
Nalates
Member
Posts: 437
Joined: Mon Dec 22, 2008 7:50 pm

Re: Public-Private Keys (WireShark)

Post by Nalates »

Maybe not – but is there a reason in the other direction? The question is not if encryption should be introduced, but if the encryption we already have should be thrown out. I don’t see a cost-benefit-tradeoff here. CPU cycles? I think what you are doing here is what is known as “premature optimization”. Have you measured that the few XOR operations (and whatever else RC4 does) have any nonnegligible effect on the total CPU usage of Uru?
Good point... we do already have it in place. So, the justification should turn around, in which case I do not have a good justification for removal. I am likely premature in optimizing.

Yes SSL... (I spend much of my day discussing these issues with artists and get lazy with terms) whether we use one or the other (SSL or Cyan's) would depend on which is more efficient... If the MOULa code is well done the difference should be small...

So, the basic reason for our current encryption is 'legacy obfuscation'... not actual security.
Nalates
GoW, GoMa and GoA apprentice - Guildmaster GoC - SL = Nalates Urriah
a'moaca'
Member
Posts: 163
Joined: Sat Dec 13, 2008 11:22 pm

Re: Public-Private Keys (WireShark)

Post by a'moaca' »

Nalates wrote:So, the basic reason for our current encryption is 'legacy obfuscation'... not actual security.
You make a lot of bad assumptions, but I shouldn't be even spending this much time right now to reply. This statement is completely wrong and I can't let it by. You continue to labor under the assumption that encryption is designed to defeat reverse-engineering, and while it certainly happens to make reverse-engineering harder, that is NOT its purpose in network communications.

Encrypting the game connection gives you actual security. It is not securing the protocol. It is securing your personal data, which includes not just what your avatar does but what you say. Have you had any conversations on the 'net that you would consider even somewhat private? Encryption is for THAT.

Encrypting the auth connection is right now the ONLY thing protecting your computer from man-in-the-middle attacks on the Python download. I think protecting your computer counts as actual security. Man-in-the-middle attacks are real. Obviously Uru is not a big target, but if I wanted a botnet I wouldn't mind an easy target. Encryption is for THAT.

Encrypting the auth connection also helps protect your username and password. A secure username and password are important parts of actual security. Without protecting those, someone could log in as you. Encryption is for THAT. (There is now fortunately also another layer of protection for passwords, at least.)

Encrypting connections does not in any way prevent client attacks on the server, because it is impossible to control what the client computer runs. That is NOT network encryption's job in exactly the same way it is NOT encryption's job to obfuscate the protocol.

The file server should be encrypted or have some other means of protecting you from man-in-the-middle attacks on the binaries downloaded, but that is no reason to throw out the rest of the system's encryption. You are definitely optimizing in the wrong place. This encryption implementation is not causing "lag". Putting in SSL instead will not "help". It is not the case that everything on the 'net is the web underneath.

And if you've taken offense at the encryption because you can't snoop your connection now, oh well. When open source happens, developers and server runners will be able to decrypt everything Just Fine without ripping out the actual security.

- a'moaca'
User avatar
Nalates
Member
Posts: 437
Joined: Mon Dec 22, 2008 7:50 pm

Re: Public-Private Keys (WireShark)

Post by Nalates »

‘Man In The Middle’ (MITM) is an interesting choice for illustrating your point… with MITM one still has to find a way to reroute the packets to do anything more than eavesdrop, meaning they still need to hijack the DNS, access point or a router. But, assuming they would put forth the time for an Open Uru server I remain skeptical that we gain much if any security for the server by the encryption of data stream. I'll know it can help. I am also skeptical about it providing much additional privacy.

With encryption our conversations are more private as they cross the network. However, anyone determined enough to hijack the data stream is going to find and easy way to monitor the conversations. Compared to hijacking a router I think reading the code to see what the server sends to the client and use it to monitor a conversation is simple. With the server code all the admin-functions are available to them. Even if Cyan keeps their admin client (if one exists) private all the server side responders are there for reverse engineering. Once we have the code we will have everything needed to know what to exploit. No key cracks needed.

Also once the route is taken over a MITM attack can sit there creating spoofed key exchanges. Christian’s link is to a wiki Diffie–Hellman entry that includes an example of how D-H can be intercepted to make their point a dual system is needed. Other papers point out the weaknesses in Diffie–Hellman. MOUL may be using large keys to make MITM more difficult. Avoidance of MITM is dependent on key size. But, that costs CPU time, which is why secure systems monitor time to see if a MITM attack is in place. Also, repeated use of the D-H key increases the likelihood it will be factored, which is why I was wondering about encrypting all the packets.

So, the points made here by Christian and a'moaca' for security and the use of encryption are valid for strong keys, I’m not sure we have the information to know whether the implementation in MOULa actually provides that. I’m not sure we know how much additional calculation the system is loaded with because of the encryption. Until we do, we can’t put it in perspective.

I do know that beyond logon Second Life and OpenSim are not encrypting the data stream. I have a proxy that I set on the data stream to SL when I want to analyze what another player in a competition is doing (are they cheating?). The efficiency of render is increasing in those systems as they shave every cpu cycle possible from the server and client. I’ve gone from 15-20 FPS with peaks of 35 to 20-35 FPS with peaks of 90. Encryption is a place to shave cycles. Considering the number of people using SL and the dollar amount of transactions taking place, I think that should add some perspective for MOULa.

There are 500 million using Facebook on open channels. The current privacy law suits are not about DNS, routers or AP’s being hijacked but about FB selling or otherwise making information available to other parties and misrepresenting their privacy. I think that should add more prospective.

Both are private for money businesses that have decided to handle their communication streams in ways used by many other companies.

While several in the community may well be concerned about security, I’m not convinced we have a realistic perspective. We have encryption and Christian well made the point it takes effort to remove it. There is no justification for removing it until we have more information. I suspect the present encryption was more for obfuscation than real security and that engenders a false sense of security.
Nalates
GoW, GoMa and GoA apprentice - Guildmaster GoC - SL = Nalates Urriah
Post Reply

Return to “Wireshark Plugin For Uru Client Protocol”