I see three fundamental security issues: Are the cards legitimately earned? Is the deck order correct? Are coins legitimately earned and spent? First we should lay out what we want to control, and then lay out a protocol to approach the problems.
Problem Statement Edit
A user controls a set of cards and coins. The user must be properly identified to the system to be allowed to manipulate their collections. (This is probably handled by the system already, and is included for completeness.)
To be legitimate, a card must be issued to the user by the game, and not have been destroyed since. A legitimate deck consists of a set of only legitimate cards, with only one instance of each.
To be a correct deck ordering, it must be randomly ordered by a trusted source, and cannot be changed during the course of the game, except by any in-game mechanism.
Electrum coins must be earned by the game, and not re-used once spent.
Requirements and Goals Edit
Currently, Elements works fine in a disconnected setting, except that you may lose changes made while disconnected if reconnection is not achieved before the browser stops running. The protocol should not interfere with this.
Changes that occur while running disconnected must be validated somehow. Validating changes made while connected is much easier, because the server can (for example) send out the next three spins, and therefore know what to expect back as the spin results. When disconnected, however, this is not possible. There are probably some tradeoffs to be made here between the amount of change that can occur during a disconnect and the security of it.
In principle there might be cards that re-ordered the deck, but that's currently not an issue in Elements. However, presumably one would want to preserve the option of doing this, so the protocol should not rely on the lack of change. One can reasonably assume that reorders are rare.
Changes That Require Control Edit
User are identified at the following times:
Cards are generated in the following ways:
- On account creation.
- Wins at the spins
- Bought at the bazaar
- Purchased upgrades
Cards are destroyed in the following way:
- Sales at the bazaar.
Deck orders are set at the following time:
- At the start of a single game
Coins are generated (earned) at the following times:
- Winning games
- Wins at the spins
- Selling cards at the bazaar
Coins are destroyed (spent) at the following times:
- Buying cards at the bazaar
- Upgrading cards
The simplest approach is to make the server central to all operations. All clients do would do would be to display the results to the users. This has the following advantages:
- All operations can be trusted because no decisions are made by the client software.
- Only the session connection needs to be validated, which is easy via https
The obvious problem is that this only works when connected. It also puts more load on the server, driving up costs. This approach is probably impractical.
One way to avoid this is to make it possible that the client software be trusted on its own. For this, there must be code running on the client system whose actions can be trusted. This is difficult because it is not possible for a server to verify that a flash file is the source of requests, not to mention whether it is the flash file the server delivered up in the first place. A cheater could write code that stood in for the client, or stood between the client and the server, and claimed to be winning 1,000 level three games in a row while the user napped. One might, for example, do this by having a local signed Java applet that ran in the same window as the flash client and stood in for the server, updating the actual server only occasionally (as now).
Another approach is to design a protocol that can work in a system in which nobody trusts each other. The server would only trust itself, and know that others have not violated the protocol. An example of such a protocol is "A Secure Poker Protocol that Minimizes the Effect of Player Coalitions". This is more than is needed, because the server itself is not a player, and is a trusted (if sometimes unavailable) third party. But using this approach, the server can send out an ordered list of pre-signed shuffles (for example) and be able to trust that the returned results were trustworthy.
Pages in category "SecureElementsProtocol"
This category contains only the following page.