Come impedire a un server compromesso di falsificare un server principale?

Vorrei impostare un modello di gioco multistrato basato su una stanza in cui i giocatori possano ospitare partite e fungere da host (vale a dire il server con potere autorevole). Vorrei ospitare un server principale che tiene traccia degli oggetti del giocatore, del grado, dei contanti, degli exp, ecc.

In un tale modello, come posso impedire a qualcuno che ospita un gioco (con un server modificato) di falsificare il server principale con risultati di corrispondenza non validi, ottenendo così exp, denaro o classifiche.

Grazie. -Cody

È stato sottolineato che la mia risposta precedente potrebbe essere stata basata su un fraintendimento di ciò che intendevi per "spoofing". (In tal caso, per favore fatemi sapere e lo eliminerò.)

Se ciò che vuoi prevenire è che i server di gioco inviano dati fasulli al server principale, allora - come osserva Jari Komppa - è generalmente impossibile da prevenire completamente. In realtà, è semplicemente una variante del classico problema di prevenzione del cheat multiplayer multiplo , tranne che con i server intermedi piuttosto che i client sospettati di barare. Molte delle stesse tecniche utilizzate per la tradizionale prevenzione della frode potrebbero funzionare anche qui, ma come al solito nessuna di esse è completamente infallibile.

Detto questo, ci sono alcune cose che potresti fare che potrebbero aiutare in particolare contro i truffatori. Uno di questi sarebbe avere ciascun giocatore in una partita contattare separatamente il server principale e confermare che stanno partecipando a quella partita. (Probabilmente si vorrà farlo prima dell'inizio della partita, in modo che è possibile assicurarsi che tutti sono d'accordo che i partecipanti sono e in modo che nessuno di tentati di affermare che non hanno partecipato in un match hanno perso. Si potrebbe usare le firme digitali per rimandare che, in sostanza, potresti avere tutti i giocatori in una partita firmare un messaggio che dice " Sono il giocatore X e sto partecipando alla partita M sul server S al momento T con i giocatori Y, Z e W."e inviarlo al server di gioco, che può successivamente inoltrarlo al server principale.) In questo modo, puoi almeno assicurarti che un server infedele non possa influenzare le classifiche di qualsiasi giocatore che non gioca effettivamente su quel server .

Ciò è particolarmente utile se stai usando qualcosa come le classifiche Elo in cui la classifica dei giocatori dipende principalmente dalle loro prestazioni relative . Certo, qualcuno che esegue un server fasullo potrebbe ancora creare un mucchio di account falsi e inviare risultati dicendo che il proprio account ha battuto quelli falsi, ma con un sistema di classificazione relativo, tutto ciò che farà è rendere l'account dell'ingannatore leggermente al di sopra dei falsi ( che a sua volta avrà valutazioni inferiori).

Un'altra cosa ovvia da fare per scoraggiare gli imbrogli è consentire ai giocatori di verificare i risultati delle loro partite direttamente dal server principale. Se un giocatore vince una partita su un nuovo server, ma i risultati inviati al server principale dicono che hanno perso (o se i risultati non vengono mai inviati), ciò farà sapere loro che sta succedendo qualcosa di sospetto. Spero che a quel punto riferiscano al server di imbrogliare, o almeno votino con i piedi e non giochino mai più su quel server.

In effetti, potresti renderlo automatico: dopo ogni partita, una volta che i risultati sono stati inviati al server principale, chiedi ai client di recuperarli dal server principale e confrontarli con il modo in cui il client pensa che il gioco sia finito. Se c'è una mancata corrispondenza, segnalalo sia al giocatore (in modo che sappiano che c'è qualcosa che non va) sia al server principale (in modo da poter rilevare i truffatori). Ovviamente, in qualità di operatore del server principale, dovrai quindi decidere chi sta mentendo - il server o il giocatore - ma speriamo nella maggior parte dei casi che sia abbastanza ovvio dal modello dei rapporti.

Nota: questa risposta può essere basata su un malinteso della domanda - vedere i commenti di seguito.

Breve risposta generica: utilizzare le firme digitali .

In particolare, il server principale dovrebbe disporre di una chiave privata per un adeguato schema di firma digitale (RSA, DSA, ECDSA, ecc.) E dovrebbe in qualche modo inoltrare in modo sicuro la sua chiave pubblica a tutti i client. Quindi il server può firmare tutti i dati che invia ai client con la chiave privata (o eventualmente usarlo per negoziare un segreto condiviso utilizzabile per crittografare e / o autenticare simmetricamente le comunicazioni tra esso e quel particolare client) e il client può utilizzare la chiave pubblica per verificare che la firma sia stata generata dal server.

Naturalmente, il prossimo problema è distribuendo la chiave pubblica in modo che un server canaglia non può parodia che e sostituire la propria chiave pubblica. Potrebbe non essere così difficile se riesci a farlo in anticipo (ad esempio distribuendo la chiave insieme all'eseguibile del gioco), ma diventa difficile se devi farlo in un secondo momento, ad esempio perché l'identità del server principale non è nota in avanzare. Una soluzione standard è quella di distribuire qualche altra chiave pubblica (la cui chiave privata corrispondente è nota solo a te) in anticipo a tutti i client, quindi firmare il messaggio contenente la chiave pubblica del server master con quell'altra chiave prima di trasmetterla.

In effetti, potresti persino estendere ulteriormente tali catene di firme, ad esempio avere una chiave privata principale super segreta, che è tenuta chiusa in un luogo sicuro e la cui chiave pubblica è nota a tutti i client e un'altra chiave privata di "uso quotidiano" che viene effettivamente utilizzato per firmare le chiavi del server e la cui chiave pubblica è essa stessa firmata con la chiave master super segreta prima che sia bloccata nella cassaforte. Questo non è così utile da solo, ma diventa potenzialmente molto utile se includi anche un meccanismo per revocare le chiavi compromesse, in modo che, ad esempio, se la tua chiave di uso quotidiano sia trapelata, puoi semplicemente revocarla e generarne un'altra.

Quello che descrivo sopra è un tipo rudimentale di infrastruttura a chiave pubblica . In realtà implementarne uno in modo sicuro può diventare piuttosto complicato, ma fortunatamente è stato fatto prima. In effetti, ogni volta che ti connetti a un sito Web (come Wikipedia ) tramite HTTPS , questo è praticamente esattamente ciò che fa il tuo browser: riceve un certificato di chiave pubblica dal server, verifica che il certificato corrisponda al nome del server nell'URL, non è elencato come revocato ed è stato firmato da un'autorità di certificazione nota e attendibile , quindi lo utilizza per negoziare una chiave di crittografia simmetrica temporaneanoto solo a se stesso e al proprietario della chiave privata corrispondente al certificato. Questa chiave simmetrica viene quindi utilizzata per crittografare e autenticare tutti i dati inviati tra il client e il server.

In particolare, dovresti davvero dare un'occhiata alle librerie SSL / TLS esistenti (che in genere vengono con un'implementazione PKI X.509 ), o eventualmente a SPKI . Questi sono ancora un po 'complicati, ma probabilmente più facili (e più sicuri) che provare a creare il tuo.

Questo dipende dalla natura del gioco e dal motivo per cui stai scaricando il ruolo del server.

In determinate circostanze potresti essere in grado di raggiungere questo obiettivo principalmente con i log di controllo crittografico. Ad esempio, se si tratta di un gioco a turni per due giocatori e puoi disporre per ogni cliente di avere una chiave asimmetrica privata per scopi di firma, puoi avere un protocollo sulla falsariga di

• Lo stato iniziale S0 include un identificatore univoco per il gioco (per prevenire gli attacchi di rigiocabilità) e si presume che sia costante. Se c'è un elemento casuale, dovrebbe essere prodotto dal server centrale e memorizzato nella cache per un confronto futuro.
• P1 fa mossa m1; firma lo stato risultante S1, producendo la firma C1; e lo invia con la sua mossa (S1, C1, m1) a P2.
• P2 fa muovere m2; firma lo stato S2 risultante, producendo la firma C2; e lo invia con la sua mossa (S2, C2, m2) a P1.
• eccetera.

Alla fine entrambi i client inviano il risultato al server centrale e, se non sono d'accordo, inviano le piste di controllo: (S1, C1, m1), (S2, C2, m2), ecc. Poiché ogni giocatore ha firmato le proprie mosse, si sono impegnati con loro.

È ancora vulnerabile a un giocatore DDOSing l'altro per impedire loro di presentare il loro risultato, ma in realtà non c'è molto che puoi fare al riguardo.

NB Questo è solo uno schizzo veloce - sono sicuro che se lo pubblichi su crypto.stackexchange.com qualcuno ci farà dei buchi enormi - ma penso che il principio sia valido. Ottieni qualsiasi schema tu progetti rivisto da qualcuno che conosce le loro cose prima di iniziare a fare affidamento su di esso.