Réseau P2P cachant des positions?

Je travaille sur une architecture P2P pour des jeux sécurisés et j'ai divisé le problème en cinq sous-problèmes:

• Modification illégale de l'état du jeu envoyé
• Supprimez avec précision les tricheurs
• Se mettre d'accord sur un état du jeu
• Éviter la triche «regarder vers l'avenir»
• Cacher des informations sensibles aux opposants

Les quatre premiers que j'ai à peu près tous résolus, mais c'est le dernier avec lequel j'ai du mal.

Avant d'entrer dans les détails, je veux juste demander s'il y a quelque chose que j'ai manqué dans ma liste de création d'un réseau p2p "anti-triche". Je ne suis pas intéressé par les astuces comme l'utilisation des aimbots, je ne souhaite que rendre le réseau p2p aussi sécurisé qu'un serveur centralisé.

Donc, jusqu'à présent, dans mes efforts pour cacher des informations sensibles, je me suis concentré sur la position des joueurs dans un jeu où la position de votre adversaire ne devrait pas toujours être connue. Le problème devient alors comment déterminer si vous devez envoyer votre position à votre adversaire sans connaître la position de votre adversaire.

J'ai exclu des méthodes telles que l'adversaire envoyant plusieurs fausses positions pour que vous puissiez également comparer la vôtre, car votre adversaire peut facilement abuser d'un tel système car il obtiendra votre position si l'une des fausses positions se trouvait "visible" de votre position.

La méthode que je me suis concentrée sur celle dans laquelle vous recevez un "champ visuel" de votre adversaire et peut ainsi déterminer si vous devez envoyer votre position ou non. C'est cependant un problème dans des jeux comme League of Legends où le champ visuel de votre adversaire est également une information très sensible. J'ai essayé de résoudre ce problème en transformant le champ visuel à l'aide d'une matrice singulière, ce qui signifie que vous ne pouvez pas revenir de la version transformée du champ visuel à la version d'origine, mais comme il s'agit d'une transformation linéaire, vous pouvez toujours déterminer si votre position est à l'intérieur le champ visuel ou non.

Cela ne fonctionne cependant pas parfaitement, le champ visuel exact ne peut pas être restauré après la transformation, mais des informations sur les "pentes" du champ visuel (le champ visuel est construit par plusieurs lignes et la pente de chaque ligne peut être déterminée) peuvent être restauré et cela peut être utilisé pour reconstruire à peu de frais le champ visuel d'origine.

En substance, j'ai besoin d'une fonction qui puisse déterminer si une position est "visible" ou non, et la reconstruction de cette fonction / champ visuel doit être si exigeante en termes de calcul qu'une fois que vous avez fini de reconstruire le champ visuel, il n'est plus pertinent pour le jeu en action. Y a-t-il une personne super intelligente qui connaît une telle méthode?

Modifier Les gens semblent un peu confus à propos de l'ensemble du "champ de vision", donc je vise à donner une explication plus détaillée ici. Le champ de vision se compose de groupes d'un ensemble de lignes, vous pouvez facilement vérifier si une position se trouve dans l'un de ces groupes en vérifiant simplement de quel côté de la ligne se trouve votre position, si elle est du même côté pour toutes les lignes de ce groupe que vous connaissez c'est à l'intérieur de ce groupe et donc à l'intérieur du champ de vision.

Les informations envoyées ne sont cependant pas cette ligne, mais une transformation de la ligne et la transformation (2 par 2 singulier une matrice), vous pouvez toujours vérifier de quel côté de la ligne se trouve votre position en la transformant d'abord en utilisant la transformation que vous avez reçue et comparer cette valeur à la ligne transformée. La clé ici est que la transformation est singulière, ce qui signifie qu'il est impossible de trouver un inverse pour revenir à la ligne d'origine. Cependant, il est possible de déterminer la pente de la ligne, ce qui rend la reconstruction de la ligne en vérifiant simplement de quel côté de la ligne transformée se trouvent de nombreux points jusqu'à ce que vous ayez identifié l'origine de la ligne beaucoup moins cher que si vous ne saviez pas la pente de la ligne.

Ce que je recherche, c'est une méthode pour déterminer si un point se trouve à l'intérieur d'une zone, où la reconstruction de la zone à partir de la méthode est soit impossible (dont je doute qu'il existe car vous pouvez toujours la forcer brutalement), soit très lourde à calculer.

Je pense que même si vous aviez un algorithme irréversible pour un champ de vision, les gens pourraient encore gagner en calculant si des points proches à eux entraîneraient une intersection de cet emplacement et un champ visuel de l'adversaire se croiserait. Dans un mauvais cas (d'un champ de vision suffisamment grand pour un rapport de carte), vous pourriez calculer par processus d'élimination le point exact de votre ennemi.

Je pense plutôt que tous les pairs connectés devraient annoncer dans quelle partie de la carte ils se trouvent, pour déterminer s'il est possible de se voir ou non. Divisez d'abord la carte en 2x2 ou 2x2x2 si la 3ème dimension est importante. Ensuite, tout le monde se dit s'il est en 1,0 1,1 0,1 ou 0,0. S'ils ne sont pas dans le même quadrant, leur conversation est terminée jusqu'à la prochaine vérification. Cela protège leur emplacement exact. S'ils existent dans le même quadrant, ils diviseront cet espace en 4 nouveaux quads et continueront jusqu'à ce qu'ils déterminent qu'ils sont suffisamment proches pour être vus les uns par les autres.

Bien sûr, il y a des problèmes avec les frontières des quadrants, mais cela devrait être résolu par des requêtes supplémentaires aux quadrants voisins.

Ne prenez pas cela comme une réponse définitive, le sujet est vraiment large (je ne serai pas surpris si quelqu'un signale votre question en fait).

Vous pouvez le résoudre en utilisant certains joueurs comme serveur, et lorsqu'un joueur est utilisé comme serveur, il ne peut pas participer au jeu des joueurs qui jouent réellement sur ce serveur .

Si votre jeu n'est pas trop exigeant, vous pouvez également exécuter plusieurs serveurs à partir de la même machine de joueur (bien sûr, cela serait utile, car tous les joueurs ne peuvent pas fonctionner comme serveur en raison de problèmes NAT, merci IPv6 !!).

Le problème principal ici est que, comme un joueur aléatoire sera utilisé comme serveur, il y a une faible chance qu'il soit un joueur "compromis" ou qu'il transmette la simulation à un joueur "compromis", permettant la transmission d'informations sensibles ( eh bien, en réalité, à ce stade, le serveur pourrait envoyer des données arbitraires et forcer la victoire de toute façon).

Si vous utilisez un serveur central pour vérifier les autorisations et les connexions, vous pourriez permettre de mieux organiser les jeux et d'interdire les joueurs facilement (mais ce ne serait plus un pur réseau P2P).

Vous pouvez également diviser le monde en tranches et calculer un hachage des tranches visibles, mais cela pourrait être facilement trompé, les tranches visibles les plus courantes permettront de construire une table de hachage assez rapidement.

Pour moi, votre question revient à essayer de rechercher une fonction cryptographique. Le test doit être rapide, mais la force brute doit être lente.

La chose la plus simple qui me vient à l'esprit (également liée à mon travail) est d'utiliser un algorithme de reconnaissance de vision rapide (de type réalité augmentée).

Si vous parvenez à faire un "instantané" rapide de votre emplacement (similaire aux tranches), qui ne peut être reconnu que lorsqu'il est placé autour de quelque chose de visible, vous allez l'avoir. Surtout s'il y a des éléments chronométrés dans la carte qui permettent de générer des modèles de reconnaissance rapides.

Cependant, même si de tels algorithmes deviennent assez rapides même sur mobile, je ne pense pas qu'ils seront assez rapides pour un jeu de tir à la première personne.

De plus, si vous les faites trop vite, vous aurez de faux positifs! Et un joueur peut de toute façon créer un jeu qui essaie quelques "visuels communs" afin que l'un des visuels soit positif pour l'algorithme de détection des fonctionnalités.

Je ne serai pas surpris que la seule solution possible à votre problème soit possible dans l'informatique quantique, et dans quelques années, quelqu'un publiera un article prouvant cette limite intrinsèque dans les réseaux P2P.

Lorsque vous dites "Cacher des informations sensibles à vos adversaires", vous voulez dire que vous voulez éviter que les personnes avec des renifleurs de paquets écoutent votre trafic et obtiennent des informations sur votre jeu?

Si c'est le cas, il y a une réponse facile à cela; la plupart des jeux AAA (et certainement des jeux sur console) utilisent le cryptage. En fait, il est si courant que de nombreux middlewares de mise en réseau utilisés dans les jeux ont déjà un cryptage de paquets intégré.

Habituellement, cela fonctionne comme ceci: Lorsque vous ouvrez une connexion à une autre machine, avant que le socket ne devienne actif, un échange de clé se produit. Je sais que sur XBox, c'était un échange de clés Diffie-Hellman; Je ne sais pas s'ils l'utilisent encore maintenant. Ensuite, une fois que vous avez vos clés, toutes les données envoyées sont cryptées à l'aide des clés et non cryptées à la réception. Si quelqu'un utilise un renifleur pour lire vos paquets, ils ressembleront à du charabia et il est peu probable qu'ils puissent les déchiffrer car ils n'ont pas les clés. (Les pirates avancés peuvent les obtenir en accédant à la mémoire de processus du jeu en cours d'exécution, mais cela est rare et peu probable.)

La seule exception à la règle de chiffrement concerne les données VoiceChat; aux États-Unis, le chat vocal doit être envoyé en clair afin que la CIA puisse écouter si elle le souhaite. Les consoles fournissent généralement un moyen de baliser les données vocales afin qu'elles ne soient pas cryptées.