[MUD-Dev] Re: Comments on Griefing Article

[J C Lawrence]

On Tue, 17 May 2005 09:36:22 -0700 (PDT)
ceo  <ceo at secureplay.com> wrote:

Given your permission, quoted below, I'm crossing this reply back to
the list.

> First, the paper was certainly not intended to be an exhaustive
> discussion of the security issues associated with games. In fact, the
> main thrust of the article was to advocate using business analysis to
> determine if security solutions are worthwhile.

An excellent goal, especially as "griefing" may be suitably defined
as "any activity which costs the service provider more revenue than
it generates".  This isn't a technical attack, it is a crack in the
trust model that allows support and operational costs to escalate
faster than saved/generated revenue.

> Your comments concerning the disclosure of private keys are mostly
> associated with "web of trust" models used for systems like PGP and
> under discussion for some anti-spam systems.

Actually, no.  I don't see the problem as one of the web of trust, but
of expense management on the part of the service provider.  Handling
registration properly is but one thing (and easy to get wrong),
operating a correct registration process along with ensuring logical
correctness across the keyspace is another, and likely a rather
expensive one.

> In such systems where individuals are allowed to self-authenticate,
> self-register, or self-certify, disclosure of private keys can
> powerfully circumvent the system.

Absolutely.  This is especially a problem as game service vendors have a
severe problem with uptake fall off due to even the smallest barrier to
entry in registration or trialling their games.

> For centralized authentication/certification/registration systems,
> this attack does not work.

Not exactly.  At the end of the day the client/edge node has to possess
its private key.  That private key is unsecured and in the possession of
a node which has very little education or self-interest in maintaining
its security.  Admittedly the key exists within an external security
context, a context which can be quite well defined and regular, but the
key itself is unsecured.  From a hacking vantage it is relatively
trivial to determine and extract such a key, distribute it widely within
a few seconds, and then generate spurious traffic using that key.  The
cost of detecting and isolating such traffic is non-trivial, and the
benefit to the malfeasos potentially significant.

> The security model and infrastructure are quite different. I did not
> spend time in the paper discussing the initial registration process
> and other means that need to be used to link an actual person to a
> private/public key pair.

True.  That's a relatively well travelled road.

> This is the most essential part of any public key
> infrastructure. Since individuals cannot freely create new
> certificates or, if registration is done properly, weaken the
> association of the certificate with the individual, the benefits of
> compromising or sharing their private key plummets -- the private key
> holder is the individual accountable for their actions and, if the
> system is managed at all, they will be excluded from the community by
> the certificate authority once they have been identified as a problem.

Which frankly, misses the point:

  1) Players don't care about their keys or point reputations, and have
  essentially no interest in wanting to help someone else to care.

  2) Service vendors can't afford to force players to care as too many
  players will simply move to another service vendor who doesn't push
  them to do something they don't care about.

  3) It is expensive for service vendors to detect and isolate
  compromised key-based traffic (intuited: O(NlogN), but could be scaled
  down through sampling methods).

At core this is a game service problem that the players want the service
providers to handle without any player participation or support UNLESS
that participation or support is fun and engaging within the game
context.  Or, of course, sufficiently financially profitable to the
players.

A comparison model in Brin-Transparent-Society style:

  Basically nobody likes traffic tickets or traffic ticket cameras.

  Posit traffic cameras with public Internet connections regularly
  spaced along every non-residential street.

  Now imagine that public citizens who determine a traffic violation via
  their own analysies of the public domain photo imagery, could gain
  some portion of the value of the ticket as a service "fee".

All of a sudden the social and economic models are tied.  I've found it
useful to think of these problems in classical economics terms (we are
talking about businesses after all), but unfortunately I've been unable
to think of an effective and direct application of such an economically
tied approach to this problem..

> This entire issue gets to the strength or weakness of PKI type systems
> - the "key" to the security of the system lies outside the
> cryptography and in the registration process.

That's only half true at best.  The strength of a PKI system depends not
only on registration, but rapid and cost-efficient detection and
isolation of spurious activity.  The best registration process in the
world is no use if the resulting data isn't used to check, verify,
isolate, and repudiate bad activity.

> Please let me know if you have any further questions or comments. By
> necessity and for the audience, the paper did not address all aspects
> of secure system design - especially since a number of issues are user
> system specific and the goal of the paper was to try to get game
> developers to start thinking about game security as a bottom line
> issue.

Sure thing.

> I have been working in the security biz since 1986 when I started at
> the US NSA and have been researching game security issues since the
> mid-1990s.  I have been the main security section author of the last
> two IGDA online game reports.

Well met sir!  Please note that my arguments are not technical.  A well
crafted PK structure is quite possible and can be proven correct in a
variety of fashions.  This is known.  The problem I'm citing is a little
different: bolting such a well crafted PK structure onto a game without
excessively increasing operational costs or losing player revenue
through lost subscriptions.

> You are welcome to post this article as you see fit.

Thanks.

> Thank you again for your interest. I look forward to continuing our
> discussion.

As do I.

--
J C Lawrence                        They said, "You have a blue guitar,
---------(*)                        You do not play things as they are."
claw at kanga.nu                       The man replied, "Things as they are
http://www.kanga.nu/~claw/          Are changed upon the blue guitar."
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://kanga.nu/lists/listinfo/mud-dev