Passer au contenu principal
Ces pratiques exemplaires sont fournies à titre de référence. Évaluez vos implémentations de façon indépendante.
Les pratiques exemplaires dépendent du type de connexion (pair à pair ou client/serveur).

​
Pair à pair

Utilisez PlayFab Party. Il gère de façon transparente le chiffrement et l’authentification pour la communication pair à pair et est fortement recommandé pour tout le trafic pair à pair dans les titres GDK. Offert sur plusieurs plateformes avec prise en charge multiréseau. Consultez PlayFab Party.

​
Client/serveur

Utilisez MsQuic. QUIC offre une sécurité et un chiffrement intégrés. Des versions GDK de la bibliothèque sont offertes en plus des builds client/serveur pour Windows et Linux. MsQuic chiffre la connexion et authentifie le serveur au moyen de certificats TLS standard; utilisez tout de même l’authentification par jeton XSTS pour authentifier le client auprès du serveur.

​
Client/serveur personnalisé

Si vous devez créer votre propre solution, utilisez DTLS avec l’authentification du serveur par certificat TLS et l’authentification du client par jeton XSTS. L’implémentation de DTLS au moyen de l’API Bcrypt du GDK est complexe et sujette aux bogues de protocole. Privilégiez OpenSSL — activement maintenu, multiplateforme et abondamment révisé. Livrez la plus récente version mineure d’OpenSSL publiquement disponible au moment de la publication du titre, et mettez-la à jour après la publication en fonction des divulgations de sécurité touchant les fonctionnalités que vous utilisez. Les dérivés d’OpenSSL ou les bibliothèques non open source ne sont pas maintenus ni révisés au même niveau — évitez-les. Configuration DTLS minimale d’OpenSSL : option de chiffrement HIGH (suites de chiffrement « high » seulement). Pour une sécurité optimale, limitez-vous aux suites de chiffrement qui incluent tous les éléments suivants :
  • AES256
  • GCM
  • SHA256 ou supérieur
Les listes de chiffrement standard d’OpenSSL contiennent encore des suites faibles qui peuvent être attaquées. AES256-GCM bénéficie de l’accélération matérielle sur XBOX et sur les processeurs modernes.

​
Authentification du serveur

Authentifiez les serveurs au moyen de DTLS à l’aide de certificats SSL dont la racine est une autorité de certification reconnue par le GDK et la plateforme. Consultez Participants au programme de racines approuvées de Microsoft. Utilisez un certificat générique pour l’ensemble des serveurs, par exemple *.servers.mytitle.com couvrant des noms comme na-1230.servers.mytitle.com. Cela permet d’utiliser des certificats préinstallés pour des instances allouées dynamiquement. MsQuic utilise le même chemin d’authentification que les requêtes Web HTTPS et expose des API de configuration pour le certificat de serveur enraciné. Consultez l’authentification du serveur dans MsQuic.

​
Authentification du client

Les clients doivent aussi s’authentifier au moyen de DTLS à l’aide de certificats enracinés dans une autorité de certification.
N’incluez pas de certificat client dans le package du titre. Il ne peut pas être lié à un utilisateur ou à une instance de client précise, il ne peut donc pas authentifier de façon sécurisée.
Émettez plutôt les certificats clients de façon sécurisée à l’exécution et validez-les au moyen d’un service de titre authentifié avec XSTS. Deux types de requêtes suffisent : 1. Émettre un certificat client Utilise les renseignements du jeton XSTS pour émettre un nouveau certificat feuille signé par l’autorité de certification client du titre (clients.mytitle.com). Faites correspondre l’heure d’expiration à celle du jeton XSTS (généralement 4 heures). Le nom du certificat inclut un nonce aléatoire sécurisé (par exemple l8n4ulxga3.clients.mytitle.com) — jamais de PII, de XUID ou de consoleID (le nonce est visible dans la négociation DTLS). Le service stocke dans sa base de données interne : le nom du certificat, le hachage, l’expiration, le XUID du joueur associé et le type d’appareil. Supprimez les entrées expirées.
Réponse en cas de réussite :
Le client suit l’expiration et utilise le certificat pour toutes les connexions DTLS; il le renouvelle au moment de l’expiration ou avant. 2. Valider un ou des certificats clients Point de terminaison réservé aux serveurs (non accessible publiquement). Reçoit des paires de certificat et de XUID attendu, et retourne valide ou non valide selon la base de données interne. Les entrées expirées ne sont pas valides. Le type d’appareil restreint davantage la validité (bloque la communication entre appareils différents).
Corps de la requête :
Réponse :
Le serveur ne poursuit que si le certificat est valide. Mettez en cache les certificats validés sur le serveur jusqu’à leur expiration. Pour plus d’efficacité, intégrez la validation aux flux de matchmaking ou d’allocation de serveurs : le service d’allocation peut retourner le nonce ou le hachage de certificat attendu et les XUID attendus pour une nouvelle session. Consultez l’authentification du client dans MsQuic. Ce flux fonctionne aussi pour le pair à pair, mais exige une grande prudence pour prévenir les attaques par certificats en double ou par sondage d’identité. Par souci de simplicité, privilégiez PlayFab Party pour le pair à pair sécurisé.

​
Numéros de séquence des messages

Incluez les numéros de séquence dans la charge utile chiffrée afin que les attaquants ne puissent pas les observer ni les modifier pour supprimer, dupliquer ou réordonner des paquets. Les numéros ne doivent pas être prévisibles :
  • Initialisez-les avec un point de départ aléatoire sécurisé et augmentez-les de façon monotone.
  • N’utilisez pas rand() ni de fonctions de hachage — elles ne sont pas sécurisées sur le plan cryptographique.
  • Utilisez BCryptGenRandom pour la valeur initiale.
MsQuic chiffre automatiquement toute la charge utile de données, y compris les numéros de séquence personnalisés.

​
Qualité de service (QoS) client/serveur

Les sondes UDP de QoS sélectionnent le meilleur centre de données ou serveur. Elles sont généralement indépendantes de l’identité de l’utilisateur et peuvent s’exécuter avant la connexion, de sorte que l’authentification et le chiffrement complets ne sont pas disponibles. Atténuez les risques :
  • N’incluez jamais de données d’utilisateur, de client ou de serveur dans la charge utile QoS. Traitez les sondes comme publiquement accessibles — randomisez la charge utile ou remplissez-la de zéros.
  • N’analysez pas les données de la charge utile. Les attaquants modifient les charges utiles pour exploiter des bogues d’analyse. Répondez uniquement en fonction des renseignements de l’en-tête du paquet.
  • Testez et renforcez l’implémentation de l’analyse QoS — gardez-la aussi simple que possible. Testez-la par fuzzing.
Gérez la QoS sur des serveurs QoS dédiés, et non sur les serveurs de jeu du titre, afin d’isoler les répercussions (y compris les attaques DDoS).

​
Documentation d’API connexe

​
Voir aussi

Dernière modification le 6 octobre 2026