> ## Documentation Index
> Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Communication sécurisée du maillage de jeu

> Conseils de communication sécurisée pair à pair et client/serveur pour les titres GDK.

<Note>
  Ces bonnes pratiques sont fournies à titre de références exemplaires. Évaluez vos implémentations de manière indépendante.
</Note>

Les bonnes pratiques dépendent du type de connexion (pair à pair ou client/serveur).

## Pair à pair

Utilisez **PlayFab Party**. Il gère de manière 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. Disponible sur plusieurs plateformes avec prise en charge inter-réseaux.

Consultez [PlayFab Party](/fr/build/console-features/networking/game-mesh/playfab-party-intro-networking).

## Client/serveur

Utilisez [**MsQuic**](/fr/build/console-features/networking/game-mesh/msquic-intro-networking). QUIC offre une sécurité et un chiffrement intégrés. Des versions GDK de la bibliothèque sont disponibles parallèlement aux builds client/serveur Windows et Linux. MsQuic chiffre la connexion et authentifie le serveur via des certificats TLS standard ; utilisez néanmoins l'**authentification par jeton XSTS** pour authentifier le client auprès du serveur.

### Client/serveur personnalisé

Si vous devez développer votre propre solution, utilisez **DTLS** avec une authentification du serveur par certificat TLS et une authentification du client par jeton XSTS.

L'implémentation de DTLS via l'API Bcrypt du GDK est complexe et sujette aux bogues de protocole. Préférez [**OpenSSL**](https://openssl.org) : activement maintenu, multiplateforme et largement examiné. Livrez la dernière version mineure d'OpenSSL publiquement disponible au moment de la sortie du titre, et mettez-la à jour après la sortie en cas de divulgations de sécurité affectant les fonctionnalités que vous utilisez.

Les dérivés d'OpenSSL ou les bibliothèques non open source ne sont pas maintenus/examinés au même niveau : évitez-les.

**Configuration DTLS OpenSSL minimale :** option de chiffrement `HIGH` (suites de chiffrement « high » uniquement). 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 OpenSSL standard contiennent encore des suites faibles qui peuvent être attaquées. AES256-GCM est accéléré matériellement sur XBOX et les processeurs modernes.

### Authentification du serveur

Authentifiez les serveurs via DTLS à l'aide de certificats SSL ancrés dans une autorité de certification reconnue par le GDK et la plateforme. Consultez [Microsoft Trusted Root Participants](https://learn.microsoft.com/security/trusted-root/participants-list).

Utilisez un **certificat générique** sur l'ensemble des serveurs, par exemple `*.servers.mytitle.com` couvrant des noms tels que `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 ancré. Consultez [l'authentification du serveur dans MsQuic](/fr/build/console-features/networking/game-mesh/msquic-intro-networking).

### Authentification du client

Les clients doivent également s'authentifier via DTLS à l'aide de certificats ancrés dans une autorité de certification.

<Warning>
  N'incluez pas de certificat client dans le package du titre. Il ne peut pas être lié à un utilisateur ou à une instance client spécifique, et ne peut donc pas authentifier de manière sécurisée.
</Warning>

Émettez plutôt les certificats clients de manière sécurisée au moment de l'exécution et validez-les via un service de titre authentifié avec XSTS. Deux types de requêtes suffisent :

**1. Émettre un certificat client**

Utilise les informations du jeton XSTS pour émettre un nouveau certificat feuille signé par l'autorité de certification client du titre (`clients.mytitle.com`). Faites correspondre le délai d'expiration à celui 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 / XUID / 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.

```http theme={null}
GET https://clientauth.mytitle.com/user([XUID])/create HTTP/1.1
Authorization: XBL3.0 x=[XSTS token information]
```

Réponse en cas de réussite :

```json theme={null}
{ "Certificate": [
  { "Client ID Nonce": "l8n4ulxga3",
    "Expiration Time": "2021-07-04 12:00:00 UTC",
    "Certificate": "[base64 private certificate data]" }
]}
```

Le client suit l'expiration et utilise le certificat pour toutes les connexions DTLS ; il le renouvelle au plus tard à l'expiration.

**2. Valider le ou les certificats clients**

Point de terminaison réservé aux serveurs (non accessible publiquement). Reçoit des paires de certificat et de XUID attendu, et renvoie valide ou non valide en fonction de la base de données interne. Les entrées expirées sont non valides. Le type d'appareil restreint davantage la validité (bloque la communication entre appareils différents).

```http theme={null}
POST https://clientauth.mytitle.com/server/validate HTTP/1.1
```

Corps de la requête :

```json theme={null}
{ "Certificate Request": [
  { "Certificate": "[base64 public certificate data]",
    "Expected Client ID": "[expected XUID]" }
]}
```

Réponse :

```json theme={null}
{ "Certificate Response": [ { "Result": "valid" } ] }
```

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 / d'allocation de serveurs : le service d'allocation peut renvoyer le nonce ou le hachage de certificat attendu ainsi que les XUID attendus pour une nouvelle session.

Consultez [l'authentification du client dans MsQuic](/fr/build/console-features/networking/game-mesh/msquic-intro-networking).

Ce flux fonctionne également en pair à pair, mais exige une grande prudence pour empêcher les attaques par certificat dupliqué ou par sondage d'identité. Par souci de simplicité, préférez **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 une **valeur de départ aléatoire sécurisée** 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 l'intégralité de 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/serveur. Elles sont généralement indépendantes de l'identité de l'utilisateur et peuvent s'exécuter avant la connexion ; l'authentification et le chiffrement complets ne sont donc pas disponibles. Pour atténuer les risques :

* N'incluez **jamais** de données utilisateur, client ou serveur dans la charge utile de QoS. Considérez les sondes comme accessibles publiquement : randomisez ou mettez à zéro la charge utile.
* **N'analysez pas les données de la charge utile.** Les attaquants modifient les charges utiles pour exploiter des bogues d'analyse. Ne répondez qu'en fonction des informations d'en-tête des paquets.
* Testez et renforcez l'implémentation de l'analyse QoS : gardez-la aussi simple que possible. Effectuez des tests de fuzzing.

Gérez la QoS sur des **serveurs QoS dédiés**, et non sur les serveurs de jeu du titre, afin d'isoler l'impact (y compris celui des attaques DDoS).

## Documentation d'API associée

* [PlayFab Party](/fr/services/playfab/multiplayer/networking) : plan voix + données avec DTLS intégré
* [Référence de l'API Networking](/fr/reference/networking/gc-reference-networking-toc) : surface Winsock et adresses d'appareil sécurisées
* [Référence de l'API XNetworking](/fr/reference/networking/xnetworking/xnetworking_members) : vérification des certificats et indications de connectivité
* [Référence Multiplayer XSAPI](/fr/reference/live/xsapi-c/multiplayer_c/multiplayer_c_members) : sessions MPSD établissant le maillage
* [Référence Multiplayer Manager XSAPI](/fr/reference/live/xsapi-c/multiplayer_manager_c/multiplayer_manager_c_members) : orchestration de plus haut niveau

## Voir aussi

* [PlayFab Party (concepts GDK)](/fr/build/console-features/networking/game-mesh/playfab-party-intro-networking)
* [MsQuic (concepts GDK)](/fr/build/console-features/networking/game-mesh/msquic-intro-networking)
* [Winsock (concepts GDK)](/fr/build/console-features/networking/game-mesh/winsock-intro-networking)
* [Vue d'ensemble du maillage de jeu](/fr/build/console-features/networking/game-mesh/game-mesh-toc)
* [OpenSSL](https://openssl.org)
* [Vue d'ensemble de la sécurité des communications](/fr/build/game-principles/security/communication-security-overview)


## Related topics

- [Répertoire des rubriques NDA : liens actifs vers Microsoft Learn](/fr-CA/nda/nda-topic-directory.md)
- [Exemples du GDK](/fr-CA/home/setup-install/samples.md)
- [XR-015 Gestion des communications entre joueurs](/fr/publishing/certification/xr/xr-015.md)
- [XR-015 Gestion des communications des joueurs](/fr-CA/publishing/certification/xr/xr-015.md)
- [Exigences XBOX testées lors de la certification pour les jeux sur console XBOX](/fr/publishing/certification/console-cert-tested-requirements.md)