Comment protéger mon jeu avec la clé CD / le numéro de série?

25

J'ai donc décidé que je voulais empêcher les copies piratées de mon jeu XNA d'accéder aux serveurs de jeux officiels (qui sont modérés, afin que les personnes qui ont payé pour le jeu obtiennent la meilleure expérience) en déconnectant les clients avec un CD erroné ou généré, en double ou interdit. clés (ou numéros de série, car le jeu est numérique et qu'il n'y a aucun CD).

Comment puis-je intégrer ce système de protection des numéros de série dans mon jeu (à la fois les clients et le serveur d'authentification principal), afin qu'il ne soit pas facilement piratable?


Notez que je n'ai aucune expérience en matière de protection de ce type pour les logiciels.

Je n'ai jamais fait cela auparavant, mais je comprends les bases. Je vois pourquoi je ne peux pas faire de vérification des clés sur le client, donc je peux utiliser l'authentification de connexion / passe avec une entrée de clé unique.

Actuellement, l'objectif de cette protection est de garder les tricheurs potentiels et les joueurs perturbateurs hors des serveurs officiels. Tout le monde peut jouer sur des serveurs privés avec ou sans clé, mais les chances d'obtenir une expérience indésirable avec d'autres joueurs sont plus grandes. Je suppose que c'est assez facile d'acheter des joueurs, car ils doivent être en ligne pour jouer sur les serveurs officiels.

Étant donné que le piratage du client est trop facile, je ne protégerai que les procédures d'enregistrement initial (et éventuellement d'authentification côté serveur), afin que personne ne puisse voler les clés pendant leur transfert.


Voir également:

Comment les jeux multijoueurs doivent-ils gérer l'authentification?

user1306322
la source
Si quelqu'un baisse les votes, j'attends au moins un commentaire sur ce qui ne va pas avec la question. Les gars, vraiment, je veux que ma question soit bonne et aide plus de gens que moi.
user1306322
4
Je suppose que c'était une réaction automatique à l'ajout de DRM. Ce type n'est pas particulièrement mauvais, mais beaucoup d'entre nous ont de mauvaises expériences avec lui - comme lorsque Spore a briqué mon installation Windows.
Izkata
Au lieu d'une clé de CD, avez-vous envisagé une approche de type MMO / Minecraft consistant à exiger un nom d'utilisateur / mot de passe pour ouvrir une session et l'utiliser pour authentifier les utilisateurs?
Tetrad
4
Vous voulez DRM sur une application .NET!? Cela échouera éventuellement avec des outils comme Reflector. Jetez un oeil à Terraria. Le développement s'est arrêté à cause du piratage (et de beaucoup de revenus ...). J'aime l'idée basée sur l'authentification de @ Tetrad car elle empêche les gens d'avoir simplement à patcher la fonction de validation. Conservez toutes les données sur votre serveur et lorsque leur connexion est réussie, alimentez-les leurs données. Si vous conservez les données localement, elles peuvent simplement corriger la fonction d'authentification.
2
@Anko qui faisait référence à la célèbre citation "Nous avons besoin de plus de minéraux" . Et je veux dire les faits et l'expertise. Peut-être même des détails. Je ne saurais pas quand un problème important a reçu suffisamment d'attention, il me semblait qu'il y avait quelque chose à ajouter, et les visiteurs du site pourraient trouver ce sujet intéressant (et peut-être devenir de nouveaux utilisateurs), alors j'ai augmenté la prime.
user1306322

Réponses:

24

Fondamentalement, vous avez trois exigences:

  1. il ne devrait pas être facile d'utiliser la même clé pour plusieurs instances client,
  2. il ne devrait pas être facile de générer de nouvelles clés valides, et
  3. il ne devrait pas être facile de voler la clé d'un client légitime.

La première partie devrait être assez simple: ne laissez pas deux joueurs se connecter au même serveur avec la même clé en même temps. Vous pouvez également demander aux serveurs d'échanger des informations sur les utilisateurs connectés ou de contacter un serveur d'authentification partagé, de sorte que même l'utilisation de la même clé pour différents joueurs sur différents serveurs en même temps échouera. Vous souhaiterez probablement également rechercher des modèles suspects d'utilisation des clés et, si vous déterminez qu'une clé a été divulguée, ajoutez-la à une liste de clés interdites.


Pour la deuxième partie, une façon consiste simplement à maintenir une base de données de toutes les clés émises valides. Tant que les clés sont suffisamment longues (disons, 128 bits ou plus) et choisies au hasard (en utilisant un RNG sécurisé), les chances de quiconque parvient à deviner une clé valide sont essentiellement nulles. (Même des clés beaucoup plus courtes peuvent être sûres si vous utilisez une sorte de limitation de débit sur les tentatives de connexion infructueuses pour arrêter les tentatives de recherche de clés valides par force brute.)

Alternativement, vous pouvez générer des clés en prenant n'importe quel identifiant unique et en y ajoutant un code d'authentification de message (tel que HMAC ), calculé à l'aide d'une clé principale secrète. Encore une fois, tant que le MAC est suffisamment long, les chances pour quiconque ne connaît pas la clé principale de deviner un MAC valide pour n'importe quel ID est négligeable. Un avantage de cette méthode, en plus de supprimer le besoin d'une base de données de clés, est que l'identifiant peut être n'importe quelle chaîne unique et peut coder des informations sur le client pour lequel la clé a été émise.

Un problème avec l'utilisation des MAC est que les serveurs de jeu officiels (ou au moins le serveur d'authentification) doivent connaître la clé principale afin de vérifier le MAC, ce qui signifie que si les serveurs sont piratés, la clé principale peut être divulguée. Une façon d'atténuer ce risque pourrait être de calculer plusieurs MAC pour chaque ID, en utilisant des clés principales différentes, mais de stocker uniquement l'une des clés principales sur les serveurs de jeu. De cette façon, si cette clé principale est jamais divulguée et utilisée pour générer de faux identifiants, vous pouvez la révoquer et passer à une autre clé principale. Alternativement, vous pouvez remplacer les MAC par des signatures numériques , qui peuvent être vérifiées en utilisant uniquement la moitié publique de la clé principale.


Pour la troisième partie, une approche consiste à s'assurer que le client n'enverra sa clé à personne sans vérifier que le destinataire est vraiment un serveur officiel légitime. Par exemple, vous pouvez utiliser SSL / TLS (ou DTLS ) pour le processus de connexion, émettre des certificats personnalisés pour vos serveurs de jeu et ne faire émettre que les certificats de confiance client. De manière pratique, l'utilisation de TLS protégera également les clés client (et toutes les autres données d'authentification) des écoutes indiscrètes, par exemple sur les WLAN publics.

Malheureusement, cette approche ne permet pas aux serveurs tiers de vérifier les clés client même s'ils le souhaitent. Vous pouvez contourner ce problème en configurant un serveur d'authentification officiel que les serveurs de jeux tiers peuvent utiliser, par exemple en demandant au client de se connecter au serveur d'authentification et de recevoir un jeton unique aléatoire qu'ils peuvent utiliser pour se connecter au serveur de jeu (qui soumet ensuite le jeton au serveur d'authentification pour le vérifier).

Alternativement, vous pouvez émettre des certificats clients réels, ou quelque chose comme eux, à vos clients. Vous pouvez soit utiliser un protocole existant (comme TLS) qui prend en charge l'authentification par certificat client (recommandé) ou implémenter le vôtre, par exemple comme ceci:

  • Le certificat client se compose d'une chaîne d'ID arbitraire, d'une paire de clés publique / privée et d'une signature numérique de l'ID et de la clé publique à l'aide de la clé principale.
  • Pour se connecter, le client envoie son identifiant, sa clé publique et sa signature. Le serveur répond avec une chaîne de défi unique (comprenant de préférence un ID de serveur et un horodatage, que le client doit vérifier), que le client signe avec la clé privée (pour prouver qu'il connaît la clé) et envoie la signature au serveur.
  • Le serveur vérifie les deux signatures, prouvant que l'ID + la clé publique forment une clé client légitime (puisqu'elles ont été signées avec la clé principale) et que la clé client appartient réellement au client (puisque le client peut signer le défi du serveur avec le privé) clé).

(Ce protocole pourrait être encore simplifié en demandant au client de générer le "défi", consistant en un ID de serveur et un horodatage, et de le signer. Bien sûr, le serveur doit alors vérifier que l'ID et l'horodatage sont valides. Notez également que ce protocole simple, à lui seul, n'empêchera pas un attaquant intermédiaire de pouvoir détourner la session du client, bien qu'il l'empêchera d'obtenir la clé privée du client nécessaire pour les futures connexions.)

Ilmari Karonen
la source
2
Un point mineur - alors qu'une clé totalement aléatoire fournit l'espace de clé maximum (et est parfaitement réalisable si vous validez par rapport à une base de données de clés émises), elle n'est pas conviviale. Mettez une certaine validation dans la clé elle-même afin que la plupart des erreurs de frappe soient détectées avant d'essayer de toucher le serveur.
Loren Pechtel
Je pense que @LorenPechtel a un point fort sur la convivialité de la clé, et l'utilisateur payé tapant accidentellement et envoyant une clé `` faute de frappe / d'orthographe '' (faute de frappe) au serveur est toujours possible.
Vishnu
@Vishnu Je sais qu'en tant qu'utilisateur qui tape des clés, je préférerais de beaucoup avoir des informations de vérification par groupe, même si cela signifiait taper une touche plus longue.
Loren Pechtel
16

Il n'y a pas de saveur à 100%, mais vous pouvez commencer avec une approche assez simple:

  • Vous aurez besoin d'un moyen de vérifier les clés générées, par exemple les sommes de contrôle incluses. Bien sûr, cela ne doit pas être trop facile à comprendre.

  • Facultatif (mais recommandé), il y aurait une base de données côté serveur vérifiant les clés avec une base de données de toutes les clés données afin que vous ne puissiez pas générer de clés, même si vous avez justement l'algorithme (ignorons le renforcement brutal).

À partir de là, vous pouvez avoir deux approches différentes, mais dans les deux cas, quelque chose est très important:

  • Ne vérifiez pas la clé côté client. C'est très important, car il est en fait assez facile de décompiler des choses écrites en .net / XNA. Si vous devez demander la clé ou la passer (connexion ou enregistrement), hachez la clé (avec un sel ajouté, etc.) et envoyez-la au serveur.

Quant aux chemins réels:

  • Exiger l'envoi de la clé hachée (voir ci-dessus) pendant la procédure d'authentification / connexion.

  • Comme alternative (IMO le meilleur, bien que beaucoup n'aiment pas ce genre de "DRM"): N'utilisez pas du tout la clé dans le client. Au lieu de cela, exigez que l'utilisateur se connecte à un compte et nécessite une clé de CD valide (cela nécessite la base de données mentionnée ci-dessus) pour créer des comptes. C'est ainsi que les jeux modernes, par exemple n'importe quel MMORPG payant, gèrent cela.

Personnellement, j'opterais pour l'approche du compte pour une raison simple: au final, vous ne pouvez pas empêcher les gens de voler des clés de CD (bruteforcing, reverse engineering ou arnaque). En tant que tel, les gens pourraient simplement créer une nouvelle clé pour continuer à jouer ou pour verrouiller les autres du jeu. Avec les clés liées au compte, personne ne peut rien faire avec une clé déjà utilisée. Si quelqu'un a acheté une clé générée par quelqu'un d'autre, vous pouvez toujours transférer la propriété du compte en supposant qu'il existe une preuve suffisante de cela.

Mario
la source
2
Au lieu de sommes de contrôle standard, vous devez utiliser un algorithme de hachage cryptographiquement sécurisé. Vous pouvez conserver la clé privée sur le serveur et donner au client la clé publique, puis vous savez que sans accès au serveur, le système est sécurisé.
Adam
@Adam: L'utilisation d'un algorithme de hachage cryptographiquement sécurisé empêchera les attaquants de générer des clés valides, mais le problème est également insoluble par l'autorité en charge de la remise des clés légitimes. En effet, une simple somme de contrôle n'est pas très sécurisée, mais les fonctions unidirectionnelles ne sont pas viables dans ce contexte.
Marcks Thomas
Eh bien, vous pouvez combiner les deux, par exemple en faisant de la première partie de la clé une combinaison aléatoire de caractères et la seconde moitié du hachage. Quiconque vend le jeu ne peut de toute façon pas utiliser un keygen (à moins qu'il n'y ait un moyen de s'assurer qu'il n'y a pas de collisions / conflits, comme un "ID de fournisseur" dans le cadre de la clé).
Mario
1

Pangea Software, créateur de plusieurs jeux Mac, a écrit un sujet sur la protection contre la copie dans son livre de développement de jeux (maintenant gratuit). Le livre explique également comment gérer les clés piratées et les autres piratages que les gens utilisent. Le livre se concentre sur le développement de jeux Mac, mais les idées pourraient toujours être utiles pour d'autres plateformes. Le livre contient le code source de chaque chapitre, qui fait partie du téléchargement ci-dessous. Il existe également du code source (écrit en C) lié à la protection contre la copie.

Le livre peut être téléchargé ici .

Wolfgang Schreurs
la source
Je n'ai rien trouvé d'utile dans ces livres.
user1306322
Personnellement, je pensais que le chapitre 16 avait de bons conseils, mais YMMV.
Wolfgang Schreurs