| |||||||||||||
On the defense of piracy enablersOn the defense of piracy enablersPosted Aug 24, 2005 15:38 UTC (Wed) by zblaxell (subscriber, #26385)In reply to: On the defense of piracy enablers by jzbiciak Parent article: On the defense of piracy enablers
Did I miss something?
I thought the whole point of the server authentication was to prevent unauthorized clients. I assume that an authorized client implements its own CD key checks, and that to get it to work at all, you'd have to modify the client to bypass at least its own checks, before you could do anything else--this is typical of pirated closed-source software anyway.
With such a client, the server could return anything--TRUE, FALSE, NULL, or 3.141592653 signed by $DEITY's PGP key--and the client would just ignore it.
(Log in to post comments)
On the defense of piracy enablers Posted Aug 24, 2005 16:11 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link] Actually, what Blizzard was arguing was that the bnetd SERVER allowed two completely unaltered bog standard clients with the same CD-Key to connect. My scheme would prevent that.
Blizzard's concept of "authorized" in this context is merely "unique CD-key with respect to all other currently logged in clients."
Remote integrity checking of the client itself can be layered onto this. I was merely discussing the CD-Key uniqueness check.
On the defense of piracy enablers Posted Aug 26, 2005 5:40 UTC (Fri) by mebrown (subscriber, #7960) [Link] Duh... maybe I'm missing something, but isn't bnetd open source? What is to prevent Evil Pirate(TM) from just commenting out your checks?
On the defense of piracy enablers Posted Aug 26, 2005 13:32 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] Right, but neither the client nor Blizzard's servers are. In this protocol, the client refuses to talk to a server unless it verifies that it can get ahold of Blizzard's servers indirectly via that server. That is, bnetd can do whatever the hell it wants. But, if it can't get the specially signed auth token from Blizzard's servers for the client, the client simply refuses to talk to it.
Like I said, this would allow any 3rd party server to work, as long as it passes through authentication requests between Blizzard's servers and clients. The bnetd server would not be able to break this due to the fact everything going each direction is cryptographically signed and thus tamper proof.
On the defense of piracy enablers Posted Aug 26, 2005 18:12 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] Let me be a little more clear:
I'm saying it's possible to achieve Blizzard's aims IF they modify their protocol and the behavior of the client.
The client needs to insist on receiving a time-stamped "token"--the time stamp's there to prevent replay attacks--that it can determine easily came from an official Blizzard server. Digitial signatures such as RSA can achieve this.
The Blizzard servers enforce the "one copy of a given CD-Key online at a time" policy by being the only source of these tokens.
A 3rd party server (such as bnetd) can still exist, passing through auth requests to Blizzard's servers and passing back replies to the clients. The 3rd party server can't fake the auth token because it doesn't have Blizzard's private key.
Such a system works because the client insists on getting a time-stamped token signed by an official Blizzard server. Now if someone hacks the client, then you're back to being a pirate. But the bnetd authors certainly cannot be blamed for others hacking their clients.
Now, you may wonder what value bnetd would have if you still needed to contact the Blizzard servers. Easy: The Blizzard servers are only handling authentication. Once the client is satisfied that Blizzard blesses its existance, the local bnetd can run the whole game. That could offer latency benefits etc.
I don't know how I could make this approach more clear. Like I said, for it to work, it requires the client to insist on reaching a Blizzard server, and for the Blizzard server to produce auth tokens that no one else can fake.
|
|||||||||||||