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

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?

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.)

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.

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 .