J'ai créé une application à l'aide de UDP pour la transmission et la réception d'informations. Le problème que je cours est la sécurité. À l'heure actuelle, j'utilise la propriété intellectuelle pour déterminer quelles données appartiennent à qui.
Cependant, j'ai lu sur la manière dont les gens pouvaient simplement utiliser leur adresse IP, puis envoyer des données comme adresse IP spécifique. Donc, cela semble être la mauvaise façon de le faire (insécurité). Alors, comment suis-je supposé identifier quelles données appartiennent à quels utilisateurs? Par exemple, vous avez 10 utilisateurs connectés, tous ont des données spécifiques. Le serveur devrait correspondre aux données utilisateur à ces données que nous avons reçues.
Le seul moyen de voir pour le faire est d'utiliser une sorte de système de clés client / serveur et de chiffrer les données. Je suis curieux de savoir comment d'autres applications (ou de jeux, car c'est ce que cette application est) assurez-vous que leurs données sont authentiques. Il y a aussi le fait que le cryptage prend beaucoup plus de temps que non crypté. Bien que je ne sois pas sûr de ce que cela affectera les performances.
Toutes les informations seraient appréciées. Merci.
6 Réponses :
Vous pouvez regarder HMAC
dans la cryptographie, HMAC (Hash-Basé
Code d'authentification du message), est un
Construction spécifique pour calculer
Un code d'authentification de message (Mac)
impliquant un hachage cryptographique
fonction en combinaison avec un secret
clé. Comme avec n'importe quel Mac, il peut être utilisé
vérifier simultanément les données
intégrité et l'authenticité d'un
message.
Chaque client aurait besoin d'obtenir un jeton unique que seulement ils savent. Chaque message qu'ils envoient, ils feront un hachage basé sur le jeton et le message et l'envoyer avec le message lui-même. Ensuite, vous pouvez vérifier que le message provenait d'un client spécifique.
HMAC est destiné à l'intégrité des données, je n'ai pas eu le point comment il empêche l'usurpation IP?
+1: un défi / réponse lors du démarrage de la session, alors chaque message aurait une signature sur (clé + clé de session) annexé
@Berkay: Il est presque impossible que le spoofer "connaisse" la graine du client (utilisée pour calculer le HMAC), de sorte que le serveur pourrait supprimer en toute sécurité toute la messagerie ne pas avoir de HMAC positif.
Quels que soient les clients sont spoofés leurs adresses IP? Vous distribuez chaque client de chaque client? Ensuite, il s'agit d'utiliser Ipsec.
Le point de l'UDP est qu'il est léger, un HMAC utilisant MD5 () a une surcharge de manière significative de manière significative dans le calcul et la bande passante que TCP qui est à l'abri de ce problème d'usurpateur. (Les HMAC sont à l'abri des collisions de hachage, de sorte que MD5 () est en sécurité.)
C'est un peu dérangeant pourquoi les gens insistent pour jeter un HMAC à tout.
@ Therook - Comment les HMAC peuvent-ils être à l'abri des collisions de hachage si le HMAC est "H" pour "hachage" ??? Si vous devez vous en tenir à UDP en raison de restrictions de mise en œuvre, vous ne pouvez pas simplement prendre TCP au lieu d'UDP.
@Robert Afin de calculer une collusion de hachage, vous devez connaître l'intégralité du message. Si vous connaissez la clé secrète utilisée dans un HMAC, vous pouvez forger le hachage résultant et générer une collision n'aide pas. De plus, plus dans l'attaque MD5 () L'attaquant doit pouvoir contrôler le préfixe du message. Si la clé est achète, une collision de hachage MD5 () est impossible. Veuillez lire "Cryptographie pratique" de Bruce Schnieier.
De plus, plus un HMAC n'est pas le système de sécurité correct pour cette vulnérabilité, qui est de plus en détail dans mon poteau.
Si vous avez absolument besoin de vérifier qu'un utilisateur particulier est un utilisateur particulier, vous devez utiliser une forme de cryptage lorsque l'utilisateur signe ses messages. Cela peut être fait assez rapidement car l'utilisateur n'a besoin que de générer un hachage de leur message, puis de signer (chiffrer) le hachage.
Pour votre application de jeu, vous n'avez probablement pas besoin de vous inquiéter de cela. La plupart des ISPS ne permettent pas à leurs utilisateurs d'utiliser des adresses IP de spoof, vous ne devez donc vous inquiéter que des utilisateurs derrière NAT dans lequel vous pouvez avoir plusieurs utilisateurs à partir de la même adresse IP. Dans ce cas, et le général, vous pouvez identifier assez en toute sécurité les utilisateurs uniques basés sur une adresse IP contenant du tuple et un port UDP.
Le point d'UDP est un poids léger. L'utilisation du cryptage augmenterait de manière significative les frais généraux du protocole par rapport à TCP qui est immunisé contre l'entrepooftage.
Je ne suis pas d'accord. Le point de l'UDP est en temps réel par opposition à fiable. Dans un environnement de jeu, vous vous souciez de la fiabilité et davantage sur la faible latence. La surcharge de la mise en place des paquets dans l'ordre est principalement due à des heures de voyage aller-retour au réseau, pas du code supplémentaire de la pile TCP. En outre, je spécule de calculer un hachage sur un datagramme et de calculer une signature pour cela n'introduit pas un goulot d'étranglement par rapport aux latences Internet moyennes.
L'utilisation d'un chiffrement d'un flux avec UDP permettrait d'économiser quelques bits de bande passante par rapport à TCP. Cependant, en général, je pense que ce système de sécurité intentionné abuse des ressources. Surtout les ressources du développeur à mettre en œuvre ce système de secuirty à dessein. SSL / TLS est une solution gratuite et la solution la plus sécurisée à ce problème.
Une solution consiste à utiliser TCP car il est à l'abri d'utiliser l'adresse source de l'adresse suivante sur l'Internet ouvert en raison de la Handshake à trois voies ( Plus d'informations sur pourquoi l'envoi de l'adresse de la source TCP est Cependant, en utilisant TCP ou UDP en tant que La couche de transport vous laisse toujours à d'autres attaques tels que renifler et Vous ne devez pas réinventer la noisette, mais si vous devez chiffrer UDP pour une raison quelconque, vous devez utiliser un chiffrement de flux comme RC4-DROP1024 ou même mieux un chiffrement à blocs comme AES 256 dans Mode OFB . Cela permettra d'enregistrer la bande passante sur d'autres modes de cryptage, car ils s'élèvent à la plus grande taille de bloc.
EDIT:
Basé sur les Martts Commentaire pour (Datagramme Transport Security) DTLS J'ai fait des creux et j'ai trouvé qu'il y a un RFC officiel et sa prise en charge par OpenSSL et doit être exposée à l'aide du Bibliothèque PyopensSL . Je recommande d'utiliser la suite Cipher RC4-SHA pour réduire les frais généraux, cette suite est prise en charge par SSL 3.0 (récente). Cependant, DTLS aura probablement plus de frais généraux (décalage!) Puis TCP.
Pour UDP, la solution utiliserait des DTLS et ne réinventerait pas la roue à l'aide de Chicheshers directement. Considérant la question originale, une affiche originale ne sera probablement pas la suivante pour la première fois.
@Mart Oruaas Cool Je ne connaissais pas les DTLS, si c'est construit à partir de TLS, vous devriez être en mesure de négocier l'utilisation d'un chiffre de flux qui passera la bande passante.
J'ai examiné TCP et cela semble être un bon choix pour empêcher ce que je demande. Cependant, de nombreux articles que j'ai lus découragent des jeux. Techniquement, une carte d'identité n'est-elle pas aussi utilisée? Il suffit d'envoyer des paquets en augmentant le # jusqu'à ce que nous obtenions une réponse qui fonctionne? Je vais regarder dans les chiffres comme ils ont l'air intéressant. Une chose à noter pour d'autres est que les données du client doivent être lues et utilisées en quelque sorte. Donc hachage que les données ne fonctionneront pas. L'ajout d'un hachage à l'avant des données augmenterait la taille des données aux niveaux insupportables.
@Chals Veuillez lire le lien "Plus d'informations" sur la raison pour laquelle cela est impossible. Avec Spoofing UDP, vous pouvez envoyer des datagrammes sortants pleins de données Bogus, mais vous devez avoir une adresse source valide afin de recevoir du trafic pour compléter une poignée de main à trois voies.
Je suis confus. Le lien fait référence à TCP, puis discutez de la poignée de main à trois voies UDP ou parlez-vous de la poignée de main à trois voies simulée plus tôt? Dites-vous parce qu'ils utilisent leur adresse, ils ne peuvent recevoir aucune réponse? Sinon, j'apprécierais une réponse plus directe. Merci.
en.wikipedia.org/wiki/ip_spoofing couvre brièvement TCP. Vous êtes à peu près droit - l'attaquant ne peut pas recevoir la réponse et que le numéro de séquence initial difficile à prédire est jeté dans le mélange, il ne peut pas faire beaucoup sans être capable d'observer le trafic légitime.
@Chals je ne suis pas vraiment sûr de votre question. Vous pouvez mettre en œuvre une poignée de main à trois sens sur tout ce qui est absolument. Je veux dire pourquoi pas? Quoi de rester spécifiquement vous de le faire?
@CHARLES Une autre chose à noter, les joueurs malveillants ne seront pas en mesure de spoiser un autre trafic de joueurs s'ils ne savent pas que les joueurs adresse IP. Je pense que la majorité des jeux comptent sur cela.
TCP n'est pas plus à l'abri de l'entrepooftage que UDP. Il pourrait forte plus difficile des paquets TCP de spoof, mais ce n'est pas impossible comme vous l'énoncez. L'entrepoiffage est un problème inhérent au protocole IP et n'est pas unique à l'un des principaux protocoles de transport.
@jathanisme Pourriez-vous s'il vous plaît expliquer comment vous envisagez d'établir une connexion TCP sans pouvoir accepter les communications entrantes. J'ai posté 2 liens pour sauvegarder mon argument et dans un environnement académique, il est approprié de poster des preuves à l'appui de vos arguments.
Je n'essayais pas de discréditer ce que vous avez énoncé, que TCP était immunisé contre l'entrepoiffage et que l'entrepoiffage d'adresse source TCP est impossible. Ces choses sont en fait possibles et sont même énoncées comme telles dans l'article que vous avez lié. L'établissement d'une connexion TCP spoofed est improbable, mais il n'est pas toujours impossible, compte tenu des circonstances correctes. La protection contre l'entrepoiffage repose fortement sur le filtrage de paquets, ce qui est malheureusement malheureusement mal faiblement par de nombreux administrateurs. ( Symantec.com/connect/articles/ip-spoofing-Introduction est une bonne ruine sur le sujet). Je voulais simplement préciser. :)
Mitm peut arriver n'importe où , (ISP, colonne vertébrale, etc.) - c'est juste une question de temps qu'il vaut la peine. Gardez à l'esprit qu'un certificat auto-signé ne vous aidera pas non plus contre MITM, à moins que vous négociez la confiance en première connexion à un serveur, auquel cas la première connexion est le point de défaillance. @CHARDLES: Les serveurs de jeu sont-ils dirigés par une organisation ou peuvent-ils les accueillir?
DTLS est probablement la solution meilleure , cependant, elle semble être Une alternative que j'ai envisagé est le Protocole de mot de passe distant sécurisé . L'avantage de cette solution est qu'il vous donne une authentification mutuelle forte (à égalité avec la sécurité de Kerberos selon les documents) et, tout aussi important dans votre cas, il fournit les deux extrémités avec une clé de session partagée pouvant être utilisée pour le cryptage. .
Compte tenu de la clé partagée, chaque paquet pourrait contenir Un inconvénient de SRP est que, en Python, le nombre de chiffres est assez lent. J'ai modifié le code de démo python dans quelque chose d'un peu plus utilisable et j'ai constaté qu'il a fallu environ 300 ms pour effectuer une seule change SRP client-serveur (CPU de 2GHz). Toutefois, une implémentation directe en C ++ de l'algorithme SRP à l'aide de la prise en charge bignombre dans OpenSSL n'a pris que 2 ms. Donc, si vous avez l'intention d'aller à cet itinéraire, je vous recommande vivement d'utiliser une implémentation C / C ++ de l'algoriiHim pour le code de production. Sinon, vous ne serez probablement pas capable de gérer quelques connexions par seconde. AES256_CBC (
Ce système de sécurité est très proche de ce que j'ai dit, sauf que vous avez laissé la partie la plus importante de ce que tout cela ajoute Lag . L'attaque est d'arrêter d'éclaboussures, non pas de perdre la perte.
@Rook: Pas vraiment. Il s'agit d'une approche spécifique de la communication UDP sécurisée à l'aide d'un protocole standard pour l'authentification et l'échange de clé. Spoofing & Eavedopping sont empêchés par cette approche et il n'y a pas de décalage induit en dehors de la poignée de main d'authentification initiale.
Je brise cela en quatre niveaux de sécurité.
Extrêmement insécurisé - Toute personne du réseau peut spoof une demande / réponse valide avec des connaissances antérieures généralement disponibles. (c.-à-d. Syslog)
très insécurisé - Tout le monde sur le réseau peut utiliser une demande / réponse valide uniquement si elles ont au moins une lecture d'accès au fil. (MITM passif) (le forum accessible HTTP avec des cookies de navigateur)
Un peu sûr - toute personne du réseau peut spoof une requête / réponse valide si elles peuvent lire et apporter des modifications au fil (actif mitm) (c.-à-d. Site HTTPS avec cert auto-signé)
sécurisé - Les demandes / réponses ne peuvent pas être spoofées même avec un accès complet à la câble. (c.-à-d. site de commerce électronique accessible HTTPS)
Pour les jeux Internet La solution très précaire pourrait être acceptable (ce serait mon choix), cela ne nécessite aucune crypto. Juste un champ de votre format de paquet UDP d'applications avec une sorte d'identifiant de session aléatoire pratiquement sans surveillable ferré pendant la durée du jeu.
Un peu sûr nécessite un peu de crypto, mais aucune de la confiance / PKI / PSK devait empêcher Active-Mitm de la solution sécurisée. Avec un peu sûr si les charges utiles sur les données n'étaient pas sensibles, vous pouvez utiliser un chiffre d'intégrité uniquement avec des DTL (TCP) TLS / (UDP) pour réduire les frais de traitement et la latence sur le client et le serveur.
Pour les jeux UDP est un énorme avantage, car s'il y a une perte de paquets, vous ne voulez pas que la pile IP ne perde pas de temps à retransmettre l'état motivé - vous souhaitez envoyer un nouvel état. Avec UDP, il existe un certain nombre de schémas intelligents tels que des cadres non reconnus (détails mondiaux qui ne comptent pas tant si leurs perdus) et des méthodes statistiques de dupliquer des données d'état importantes pour contrer des niveaux prévisibles de perte de paquets observée.
À la fin de la journée, je recommanderais d'aller très peu sûre ou une intégrité sans peu précaire / W DTLS uniquement.
Je regarderais dans la bibliothèque de réseau de jeux de garage. Il est écrit en C ++ et utilise UDP. Il est conçu pour une faible latence et est considéré comme l'un des meilleurs pour les jeux.
Si je me souviens bien, ils calculeraient en fait la position probable du joueur sur le côté client et le côté serveur. Cela ferait cela pour de nombreux aspects pour assurer l'intégrité des données. Il ferait également une vérification du CRC sur le logiciel client et comparera le logiciel serveur pour vous assurer qu'ils correspondent.
Je ne suis pas sûr que vous puissiez plus de licence séparément afin que vous puissiez avoir à licencier le moteur de jeu (100 dollars). Cela vous donnerait au moins une idée d'une approche éprouvée de UDP pour les jeux. Une autre possibilité regrette le code de réseautage pygame. Cela peut avoir déjà abordé les problèmes auxquels vous faites face.
Vous voudrez peut-être envisager une sorte de tunneling tel que SSH ou IPSec. La seule façon dont vous allez affirmer qui est qui est à titre d'authentification.
@jathanisme Qu'en est-il du décalage? Et ce qui ne va pas SSL / TLS / DTLS?
Rien ne va pas avec SSL / TLS / DTLS, je proposais simplement des alternatives. Spécifiquement, SSL nécessite des certificats signés, à moins que vous n'utilisiez des certificats auto-signés, vous n'obtenez vraiment pas beaucoup à l'exception du cryptage.