Multiplayer Game Protocol Requirements and Design Document (Revised)

1. Overview

This protocol provides a modular, secure, and real‑time communication mechanism for multiplayer turn‑based games. Its design enables rapid setup for both simple games (e.g., Tic Tac Toe) and complex games (e.g., Chess). Key features include:

Dynamic (“Rolling”) Topics:
Topics are computed dynamically for each game round using a cryptographic hash function on a round number and a secret seed. The seed disclosure is controlled—initially only its hash is published, and it is revealed later in a server‑controlled manner. This prevents outsiders from predicting or preempting game channels.
Ephemeral (Per‑Game) Keys:
Every participant (clients and server) generates new, short‑lived key pairs (preferably ECC for performance) for each session. These keys are used for signing messages and for challenge–response authentication during the game session. Long‑term identity keys remain separate and may be bound to player identities via pre‑registration or server-signed certificates.
Mutual Authentication via Challenge–Response:
A nonce‑based challenge–response mechanism ensures that no entity (or impersonator) can act in another’s name. All messages are digitally signed and include nonces, sequence numbers, and timestamps to prevent replay.
Tamper‑Evident Activity Log (Blockchain‑Style):
Clients maintain an append‑only log of game actions. Each block includes a hash of the previous block, a list of actions, a digital signature, and proper sequence numbering. Blocks are broadcast on a common log topic, and a lightweight consensus mechanism (or server arbitration) is used to resolve any conflicts.
Mandatory Transport Security:
All MQTT communications are assumed to use TLS to ensure confidentiality and integrity. This is critical for protecting the seed, key registrations, and game messages in transit.

2. Functional Requirements

2.1. Session Initialization and Key Registration

Ephemeral Key Generation:
- Every entity (clients and server) generates a new ephemeral key pair at the start of each game session.
- Recommendation: Use ECC (e.g., Curve25519 or similar) for faster key generation on resource‑constrained devices.
Key Registration & Dissemination:
- Each participant publishes a registration message containing their ephemeral public key on a dedicated MQTT topic (e.g., game/register/<playerId>).
- These messages are published with the retain flag and an appropriate QoS (e.g., QoS 2) to guarantee exactly‑once delivery.
- Server‑Signed Registrations:
  Optionally, the server can sign these registration messages or bind them to pre‑registered game PINs or secrets to thwart impersonation on the first use.
- Trust Model (TOFU):
  Clients accept the first registration message received for a given player and store the key for the session. Subsequent conflicting keys trigger an alert as potential impersonation.
Retained Message Management:
- At the end of the session, the server is responsible for clearing retained registration messages so that stale keys are not reused.

2.2. Dynamic Topic Rolling and Round Coordination

Round Coordination:
- The server generates a random secret seed and a monotonically increasing round number at the beginning of each round.
- Two‑Stage Control Message:
  1. Announcement: Publish a control message on a known topic (e.g., game/config) with the round number and hash(seed). This message uses QoS 2.
  2. Seed Release: At the round’s start, publish another control message on the same (or dedicated) topic containing the secret seed (with a digital signature by the server’s ephemeral key). Clients verify that the hash matches the earlier announcement.
- This two‑step process ensures that the seed remains undisclosed until it is time to compute the dynamic topic.
Dynamic Topic Calculation:
- Each client computes the round’s game topic as:
```
topic = "game/room1/" + SHA256(round_number || secret_seed)[0..12]
```
- Because the seed is only revealed at round start and is transmitted over TLS (and signed by the server), only authorized clients can compute the topic. The unpredictability of the seed (and the use of a hash) prevents outsiders from precomputing future topics.
Topic Usage:
- All game moves and related messages for that round are published on the computed, dynamic topic.
- At the end of a round, the topic is archived; a new round begins with new ephemeral keys, a new seed, and a new topic.

2.3. Gameplay & Move Communication

Move Submission:
- Clients post game moves over the dynamic topic with each move message containing:
  - The move or action details (in a generic JSON schema).
  - A digital signature computed using the sender’s ephemeral private key.
  - A nonce or sequence number and timestamp.
- QoS Consideration: Use at least QoS 1 for moves; critical messages (e.g., registrations, logs) should use QoS 2.
Challenge–Response Authentication:
- When a client needs to verify another’s authenticity, it sends a challenge (a random nonce) over a client‑specific channel (e.g., game/challenges/<playerId>) or over the dynamic topic with intended addressing.
- The challenged client signs the nonce and replies on a common response topic.
- Replay attacks are prevented by using unique nonces and including timestamps/sequence numbers.

2.4. Client‑Side Activity Log (Blockchain‑Style)

Block Structure:
- Each block in the log must include:
  - Block Number & Timestamp: For ordering.
  - List of Game Actions: Actions/moves aggregated, in a canonical JSON format.
  - Previous Block Hash: To form a tamper‑evident chain.
  - Block Hash: Computed over the current block’s entire contents.
  - Digital Signature: The creator’s signature over the block, ensuring authenticity.
- Blocks might look as follows:
```
{
  "blockNumber": 5,
  "timestamp": "2023-10-20T12:34:56Z",
  "actions": [
      { "player": "Alice", "move": "attack", "target": "Bob", "value": 30 },
      { "player": "Bob", "move": "defend" }
  ],
  "prevBlockHash": "a1b2c3...",
  "blockHash": "d4e5f6...",
  "signature": "signature_value"
}
```
Log Broadcast and Verification:
- Blocks are broadcast on a shared log topic (e.g., game/room1/log) using QoS 2.
- Each client verifies:
  - That the previous block hash matches its current state.
  - The correctness of the block’s hash.
  - The digital signature (using the sender’s public key).
- Consensus for the Log:
  - A server‑mediated lightweight acknowledgement (or majority voting) may be used for new blocks.
  - Conflicts or forks are resolved by deferring to the server as the arbitrator or by taking the block with the most acknowledgments.
Immutability Constraints:
- With hash chaining and digital signatures, rewriting any block would require re‑computing all subsequent blocks and forging signatures.
- Clients store their logs locally (safely) and synchronize with each other upon reconnection via a game/sync topic.

3. Security Requirements

3.1 Message Integrity and Authentication

Digital Signatures:
All messages (registrations, challenges, moves, logs) include digital signatures computed with ephemeral private keys. Recipients verify these using the corresponding public keys.
Replay Prevention:
Unique nonces, monotonically increasing sequence numbers, and trusted timestamps are included to thwart replay attacks.

3.2 Transport Security

TLS Mandate:
All MQTT communications must run over TLS to provide confidentiality and integrity in transit.
This protects seeds, keys, registration messages, and game moves from eavesdropping and MITM attacks.

3.3 Key Registration and Impersonation Resistance

Server‑Signed Registrations / Pre‑Shared Secrets:
Registration messages should be attested by the server (or use a game PIN) to prevent an adversary from publishing a fraudulent ephemeral key before the legitimate client connects.
TOFU with Validation:
Once a client's registration is accepted, any subsequent registration for that player that does not match is flagged. This minimizes impersonation risk during the initial key exchange.

3.4 Securing the Activity Log

Hash Chaining and Block Signing:
Every block in the log is chained using the previous block’s hash and signed by its creator. Altering any block invalidates subsequent blocks.
Distributed Consensus:
A lightweight consensus mechanism (or server log arbitration) provides a canonical log state across clients.
Retention and Synchronization:
Clients must sync any missed blocks on reconnection via a dedicated sync topic.

3.5 Additional Considerations

Reconnection Handling:
Clients, upon reconnecting, fetch the latest control messages, registration data, and log blocks from retained messages or via a game/sync topic.
DoS Mitigation:
The MQTT broker should be configured for rate limiting. Client-specific channels for challenges and acknowledgments help isolate potential floods.
Payload Encryption (Optional):
For sensitive game data, establish a shared symmetric key (via an ECDH key agreement using ephemeral keys) and encrypt payloads in addition to signing.
QoS and Reliability:
Use MQTT QoS 2 for critical messages (e.g., registrations, seeds, log blocks) and QoS 1 for regular game moves to balance reliability with performance.

4. Generic Use Across Multiple Games

Game-Agnostic Schema:
The protocol defines a generic JSON schema for messages with standard fields (e.g., action, player, details, timestamp). Game-specific interpretation (e.g., Tic Tac Toe positions vs. Chess moves) is handled at the application layer.
Round Flexibility:
The dynamic topic mechanism is independent of game rules. Rounds can last a few moves or an entire game, and clients simply compute a new dynamic topic for each round.
Extensible Activity Log:
The blockchain‑style log is generic and can record any type of game action. Its immutability provides an audit trail regardless of game complexity.

5. Message Flow Summary

Initialization:
- Key Generation: Clients and server generate ephemeral keys (ECC recommended) at session start.
- Registration: Each entity publishes its registration message (with retained flag and, ideally, a server signature or pre‑shared secret) on its designated topic.
- Transport Security: All messages are delivered over TLS.
Round Start Coordination:
- The server publishes a control message (game/config) with the round number and hash(seed) (using QoS 2).
- When the round begins, the server publishes the secret seed (signed) on the control channel.
- Clients verify the seed by matching its hash and then compute the dynamic game topic as:
```
topic = "game/room1/" + SHA256(round_number || secret_seed)[0..12]
```
Gameplay and Authentication:
- Players broadcast moves, challenges, and responses on the dynamic topic and/or their dedicated challenge channels.
- Each message carries a nonce, sequence number, and signature to ensure its authenticity and freshness.
Activity Log Maintenance:
- Clients create and broadcast blocks containing game actions, previous block hashes, timestamps, and their digital signatures.
- A lightweight consensus or server arbitration mechanism verifies that all clients maintain an identical, tamper‑evident chain.
Session Termination and Transition:
- At session end, the server clears retained registration and control messages.
- Clients store their logs securely and can later synchronize for dispute resolution or replay verification if needed.
- A new session begins with a fresh set of ephemeral keys, a new secret seed, and a new dynamically computed topic.

6. Future Considerations and Extensibility

Federated Server Architecture:
For scalability, multiple servers may collaborate using a Byzantine Fault-Tolerant (BFT) or similar consensus mechanism.
Periodic Checkpointing:
Anchor log block hashes externally (e.g., on a public blockchain) for added non-repudiation.
Turn Mediation and Game Rule Enforcement:
The server can take a more active role by validating moves before appending them to the canonical log.
Key Rotation During Long Sessions:
Mid-session rotation of ephemeral keys can further limit exposure if keys are compromised.
Enhanced DoS Protection:
Consider additional client authentication and rate limiting tuned to your expected game load.

Summary

This revised protocol specification details a secure, dynamic, and flexible multiplayer game environment using MQTT as the communication substrate. By utilizing:

Dynamic, hash‑derived topics coordinated by a securely distributed seed,
Ephemeral key pairs generated fresh for each session with robust TLS‑backed transport,
Mutual authentication through nonce‑based challenge–response,
A tamper‑evident blockchain‑style activity log that incorporates hash chaining, digital signatures, and distributed consensus,

the system ensures that all game communications are both authentic and resistant to tampering or impersonation. These measures are designed to be robust enough for lightweight games like Tic Tac Toe and scalable to more intricate games such as Chess.

Future enhancements include better replay prevention via sequence numbers, explicit handling of client reconnection, and optional message encryption for privacy. This document can serve as the foundation for a secure, generic multiplayer game protocol adaptable to varying game rules and network conditions.

Staninna/mqtt.md