[MUD-Dev] Trusting the client, encrypting data

[Alex Chacha]

Richard A. Bartle wrote:
> Jessica Mulligan wrote:

>> I don't think any kind of encryption scheme for client data is
>> going to survive for long.

> I agree. A bogus client doesn't need to know anything about public
> key encryption in order to work. All it needs is the code ripped
> out of the genuine client that does know it.

To date there has not been any software cryptosystem that did not
have a weakness to a simple ICE (in circuit emulator) attack, where
all you do it send a hardware breakpoint to the debugger and then
copy the machine code that handles security and while at it copy the
memory block where the key resides.  This is not attacking the
cryptosystem or it's implementation, it is simply exploiting the
vulnerability of the machine and the memory space of the process.
If a debugger can access the process where the program runs, that
program can be compromised.

Since the environment of the client program can be considered
hostile, the only way to have a completely secure system against an
attacker is to run the client code inside a secure co-processor with
FIPS 140-1 level 4 certification (like IBM 4758:

  http://www-1.ibm.com/servers/eserver/zseries/library/specsheets/pdf/g2219091.pdf

or similar) where the hardware is completely secure and any attempt
at tampering will cause it to self destruct and destroy its private
key along with the rest of the code.  This is completely
unreasonable, and given the complexity of the clients, impossible to
do (I have not seen any secure co-processor that runs over 100Mhz
(NSA may prove me otherwise I am sure), since the CPU is usually
encased in epoxy, heat dissipation is a serious issue, so no modern
commercial processor can run in that environment without melting).
Another major point is that people don't want to spend lots of money
to play their favorite game.  So complete security for the client is
a pipe dream at this time (and time to come unless computer makers
make drastic changes).  Furthermore, how many people will be willing
to pay for encryption hardware to play their favorite game (the
answer is probably: the same people that would buy a complete VR
outfit, few at best, at this point in time).

Given that complete security is an impossibility at this point in
time, all the software schemes can do is prevent majority of the
user base from hacking the client and forcing it to trick the
server.  The designers and developers need to assume that the client
is the weak link and there is nothing they can do to prevent the
hardcore hackers from hijacking the client.  The question they
should ask is not how to completely secure the client, but how to
make sure that a security exploit is not easily reproducible without
the presence of the hardcore hackers.  How to prevent the
"script-kiddie" phenomenon.

If a few people hack the client and use the exploit, it may be
acceptable in a sense that you can audit the logs and find these
anomalies and ban the hackers.  If a large percentage of the
community is using some script hack, then the situation is quite
grave (no pun intended). This can easily kill a game (mudflation
being the immediate result, followed by trivialization of content
and then a rapid exodus of the user base).  There are many books,
papers and articles written about how to relatively secure a system
(so I'll avoid the details here), but it is very important that the
client is secured from "most" of the players and that there is a way
to quickly change the security properties and to prevent any script
hack from lasting more than a few uses before it is rendered
useless.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev