這些最佳做法僅作為範例參考。請自行獨立評估您的實作。
對等
使用 PlayFab Party。它會以透明方式處理對等通訊的加密和驗證,強烈建議用於 GDK 遊戲中的所有對等流量。它可在多個平台上使用,並支援跨網路。 請參閱 PlayFab Party。用戶端/伺服器
使用 MsQuic。QUIC 提供內建的安全性與加密功能。除了 Windows 和 Linux 用戶端/伺服器組建外,也提供此程式庫的 GDK 版本。MsQuic 會加密連線,並透過標準 TLS 憑證驗證伺服器;但仍請使用 XSTS 權杖驗證,向伺服器驗證用戶端。自訂用戶端/伺服器
如果必須自行實作,請使用 DTLS,搭配伺服器 TLS 憑證驗證與用戶端 XSTS 權杖驗證。 透過 GDK Bcrypt API 實作 DTLS 相當複雜,而且容易產生通訊協定錯誤。建議優先使用 OpenSSL:它持續維護、跨平台,且經過廣泛審查。請在遊戲發行時隨附最新公開提供的 OpenSSL 次要版本,並在發行後針對影響您所用功能的安全性揭露進行更新。 OpenSSL 衍生版本或非開放原始碼程式庫並未受到同等程度的維護/審查,請避免使用。 最低 OpenSSL DTLS 設定: 加密選項HIGH (僅限「高」加密套件)。為了達到最佳安全性,請限制為同時包含以下所有項目的加密套件:
- AES256
- GCM
- SHA256 或更高
伺服器驗證
透過 DTLS,使用以 GDK 和平台認可之 CA 為根的 SSL 憑證來驗證伺服器。請參閱 Microsoft 信任的根參與者。 在各伺服器之間使用萬用字元憑證,例如以*.servers.mytitle.com 涵蓋 na-1230.servers.mytitle.com 之類的名稱。這樣可為動態配置的執行個體預先安裝憑證。
MsQuic 使用與 HTTPS Web 要求相同的驗證路徑,並公開用於根伺服器憑證的設定 API。請參閱 MsQuic 中的伺服器驗證。
用戶端驗證
用戶端也應透過 DTLS,使用以 CA 為根的憑證進行驗證。 請改為在執行階段安全地發行用戶端憑證,並透過經 XSTS 驗證的遊戲服務來驗證這些憑證。兩種要求類型就已足夠: 1. 發行用戶端憑證 使用 XSTS 權杖資訊發行由遊戲用戶端 CA (clients.mytitle.com) 簽署的新分葉憑證。將到期時間與 XSTS 權杖相符 (通常為 4 小時)。憑證名稱包含安全的隨機 nonce (例如 l8n4ulxga3.clients.mytitle.com),絕對不要包含 PII / XUID / consoleID (nonce 在 DTLS 交握中是可見的)。
服務會在其內部資料庫中儲存:憑證名稱、雜湊、到期時間、關聯的玩家 XUID、裝置類型。請移除已過期的項目。
訊息序號
將序號包含在加密的承載中,讓攻擊者無法觀察或修改序號來丟棄、複製或重新排序封包。序號不應可預測:- 以安全的隨機起始值初始化,並單調遞增。
- 不要使用
rand()或雜湊函式,它們在密碼編譯上並不安全。 - 使用
BCryptGenRandom產生種子。
用戶端/伺服器服務品質 (QoS)
QoS UDP 探查會選取最佳的資料中心/伺服器。它們通常與使用者身分無關,而且可能在登入前執行,因此無法進行完整的驗證和加密。緩解方式:- 絕對不要在 QoS 承載中包含使用者、用戶端或伺服器資料。將探查視為可公開存取,請將承載隨機化或歸零。
- 不要剖析承載資料。 攻擊者會修改承載以觸發剖析器錯誤。只根據封包標頭資訊做出回應。
- 測試並強化 QoS 剖析實作,盡可能保持簡單。並對其進行模糊測試。
相關 API 文件
- PlayFab Party:內建 DTLS 的語音 + 資料平面
- 網路 API 參考:Winsock 介面與安全裝置位址
- XNetworking API 參考:憑證驗證與連線提示
- XSAPI 多人遊戲參考:建立網狀架構的 MPSD 工作階段
- XSAPI Multiplayer Manager 參考:較高層級的協調流程
