Xbox One Secure Communication Requirements

Last Updated: July 6, 2017

Introduction

The Xbox One console provides a set of secure communication methods that can be used by a title for console-to-console and console-to-service or server connections. Securing communication is critical to ensure the confidentiality, integrity, and availability of the Xbox One console, Xbox Live Services, and third-party publisher services.

The following API sets are available through the Xbox One platform:

IXMLHttpRequest2
  This API is the only permitted HTTP API for Xbox One titles to access web services. HTTPS has to be used for all web requests. Communication through this API is limited based on the endpoints listed in the Network Security Authorization List (NSAL) that is configured for a title on the Xbox Developer Portal (XDP). This limitation protects the console and title from unwanted or erroneous connections.

StreamWebSocket/MessageWebSocket
  This API provides WebSocket functionality for web endpoints. It requires the usage of HTTPS to create Secure Sockets Layer (SSL)/Transport Layer Security (TLS)-encrypted TCP socket connections. We recommend this API for securing TCP socket communication with title servers/services.

Secure Socket
  This API provides secure raw socket communication (TCP and UDP) for console-to-console and console-to-Xbox Live Compute connections. The APIs abstract an underlying Internet Protocol security (IPsec) tunnel and allow a title to use WinSock2 APIs after establishing the secure tunnel. Secure sockets are the required connection method for console-to-console and console-to-Xbox Live Compute scenarios.

BCrypt
  This API provides cryptographic functionality that can be used to create secure UDP connections to servers/services. This custom encryption approach should not be used for other connection scenarios and requires sign-off from Microsoft before you submit your title for certification.

Securing your network traffic

Network traffic to and from the Xbox One console must be protected by both encryption and integrity protection. This ensures confidentiality, integrity, and availability of the Xbox One console, Xbox Live Services, and third-party publisher services.

Selecting the correct secure communication method

The following list describes the recommended secure communication methods for a title:

Xbox One/Xbox One (UDP and TCP)
  Connections between Xbox One consoles have to be secured through the Secure Socket APIs. Secure Socket APIs provide a secure tunnel for UDP and TCP traffic between consoles and are a requirement for certification.

Xbox One/Windows 10 (UDP and TCP)
  Connections between Xbox One consoles and Windows 10 have to be secured through the Secure Socket APIs. Secure Socket APIs provide a secure tunnel for UDP and TCP traffic between consoles, are a requirement for certification, and are available on Windows 10.

Xbox One/Xbox Live Compute (UDP & TCP)
  Connections between the Xbox One console and Xbox Live Compute instances should be treated like console-to-console connections. The same Secure Socket API functionality is available for UDP and TCP connections. Under certain circumstances this API functionality may not be sufficient for a title. Please contact your developer account manager if you run into connection constraints.

Xbox One/Web Service (HTTPS)
  All connections to web services are required to use TLS (HTTPS) and the IXMLHttpRequest2 APIs on the console. Other HTTP client libraries are not permitted on the Xbox One console. Connections to web services should also include an XSTS token for authentication and authorization when possible.

Xbox One/Title Server (TCP)
  TCP connections to a title server from the Xbox One console should be performed through the StreamWebSocket/MessageWebSocket APIs through an HTTPS endpoint. These APIs provide a transparent TLS tunnel and require no further work or sign-off for securing a TCP connection to a server.

Xbox One/Title Server (UDP)
  UDP connections to a title server from the Xbox One console are not automatically secured. A title is required to create a custom secure communication protocol to protect this connection through the use of the BCrypt library on the Xbox One console. The use of other cryptography libraries are not permitted on the Xbox One console. A custom security protocol requires sign-off from Microsoft prior to certification. A sample custom secure communication design is available later in this document.

Table 1: Summary of recommended secure communication methods for a title.

  Xbox One/
Xbox One		 Xbox One/
Windows 10		 Xbox One/ Xbox Live Compute Xbox One/
Web Service		 Xbox One/
Title Server
TCP Secure Socket API Secure Socket API Secure Socket API IXHR2 (HTTPS) StreamWebSocket/
MessageWebSocket
(HTTPS)
UDP Secure Socket API Secure Socket API Secure Socket API n/a Custom Secure Protocol through BCrypt
Authentication XSTS token XSTS token XSTS token XSTS token/
SSL Certificate		 XSTS token (indirectly or directly)

Note For “Secure Socket API” on Xbox Live Compute, contact your developer account manager if you encounter API limitations. For “Custom Secure Protocol through BCrypt,” a security review is required before certification.

SSL/TLS/WebSockets

When using SSL, clients should only use TLS 1.2.

Prior versions of SSL, TLS 1.0, and TLS 1.1 are vulnerable and must not be used under any circumstances. For approved cipher suites, see the recommended cryptographic libraries later in this white paper.

Xbox Live Compute

Titles leveraging Xbox Live Compute should use the Xbox Live Compute SDK, which uses secure sockets for network encryption and integrity protection. Titles implementing protocols or other design patterns outside of the Xbox Live Compute SDK should discuss this with their developer account manager.

Authentication

Both client and server authentication is key to establishing a secure trusted service or server connection. Authentication is automatically performed for Secure Socket Layer connections. However, all other communication with Xbox One title services and servers must provide the appropriate level of authentication based on the value of the traffic being communicated over the network. Customer data, payment instrument information, authentication tokens and/or other regulated, high value data must always use authenticated endpoints and be transferred by using the most secure channels possible.

Server authentication

All Xbox One clients should utilize SSL certificates to authenticate service endpoints through IXHR2 or WebSocket APIs. For UDP connections, a per-session key should be established through a trusted endpoint prior to establishing a UDP connection. For more information, see Custom secure protocol through BCrypt later in this white paper.

Note: As of May 2017, the use of SSL certificates with SHA-1 is fully deprecated. All server certificates should use SHA-256 (or larger) from now on. For more information, see Windows Enforcement of SHA1 Certificates.

Client authentication

Client authentication is important for most services and should be used for all title services and servers. The Xbox One console does not provide title access to the certificate store like on a Windows platform. Instead titles should leverage an XSTS authentication token to authenticate the client. For more information about XSTS token authentication, see the white paper Your Xbox One Title, XSTS Tokens, and Web Services.

Custom secure protocol through BCrypt

If a title communicates with a title server through UDP, it has to implement a custom secure protocol to provide confidentiality and integrity. To enable this communication, an insecure socket usage definition has to be used in the network manifest (see Appendix A). This insecure usage will trigger the requirement for a security review prior to certification. Try to work as early as possible with your developer account manager to ensure appropriate review.

To implement a custom security protocol, you must use the cryptographic library known as BCrypt (also known as CNG). BCrypt is a C API set that includes implementations for many popular algorithms. It is included with the Xbox One XDK and is cross-platform compatible between the Xbox One and all versions of Windows from Windows Vista through Windows 10 and from Windows Server 2008 through Windows Server 2012 R2.

When building a custom security protocol, the following three points must be core to the design:

  1. Protect the confidentiality of the data so that it cannot be read by an attacker. Confidentiality is typically achieved by encryption through BCrypt. Confidentiality also includes authentication of the client and the server/service.
  2. Protect the integrity of the message so that it cannot be altered by an attacker. Integrity protection is typically achieved by signing the data with a Hash-based Message Authentication Code (HMAC). This ensures that the receiver can detect any tampering of message content.
  3. Protect against replay of messages. Replay protection is typically achieved by including a sequence number in the message. Messages with duplicate sequence numbers can be discarded by the receiver. Replay protection requires integrity protection.

A title has to provide confidentiality, integrity, and replay protection to pass the required security review. In addition, custom security protocols must not use reserved platform ports when performing communication on the Xbox One console. For a list of the reserved ports, see the XDK documentation topic Reserved Ports and Firewall Exceptions.

For a high-level description of a design that provides both of these core points, see the Sample custom secure communication design section later in this white paper.

Third party/open source cryptography libraries

In case a title requires an additional algorithm that is not present in the BCrypt library, the use of a third-party or open source cryptographic library might be permissible. If this applies to your title, contact your developer account manager to request approval.

The use of third-party libraries is not permitted for functionality that is already provided through existing platform libraries such as BCrypt, IXHR2, or WebSocket APIs. The developer assumes responsibility to ensure that any used libraries are implemented securely and updated through content updates to the title in the case of a security vulnerability.

Cryptographic algorithms

The following table lists common cryptographic algorithms and their security level. Algorithms that are listed as insecure are not permitted for Xbox One titles, and their use in a custom security protocol will result in a security review failure.

Figure 1.  Common cryptographic algorithms and their security level.

Note CCM, GCM - These modes provide integrity and authenticity but are generally regarded as difficult to implement and should be avoided when implemented from primitives.

Note RC4 >= 128bit key - For a secure implementation of RC4, titles must drop/discard the first 1 KB of data encrypted, must have short lived keys, and must never re-use keys. Additionally, the data must also be signed because RC4 can be manipulated in predictable ways.

Sample custom secure communication design

The following design is a recommended approach for handling custom secure socket connections to a title server through UDP. It does not represent the only possible approach, but it is the recommended flow and it limits issues during the security review of a title.

Secure connection flow

To ensure that UDP connections are authenticated and secured, the recommended design uses the following components:

Key Distribution Webservice
  This custom web service is used to generate session-based symmetric keys for encryption. Connections to this service require HTTPS and an XSTS token for authentication.

Title server
  The Key Distribution Webservice shares session-based symmetric keys with title servers. The title servers use this key for symmetric encryption between the Xbox One client and server.

With these two components, it is possible that only authenticated clients connect to title servers, and title servers will only communicate with valid players through the following flow:

Figure 2.  Secure connection flow.

  1. Request keys

The title on the Xbox One console first sends a RESTful request to the Key Distribution Webservice through IXHR2. The request includes an XSTS token with at least the following claims: TitleID, XUID, and privileges.

  1. Verify client XSTS token

The Key Distribution Webservice uses the claims for authentication in the following way:
* TitleID: to support multiple titles and validate the correct title
* XUID: to diagnose user tracking and to throttle requests
* Privileges: to validate the user’s multiplayer privilege on the service

For more information about configuring and retrieving claims from XSTS tokens, see the documentation for XSTS token validation.
1. Generate keys

  1. Generate keys

If the user’s authentication succeeded, the Key Distribution Webservice generates an AES256 symmetric key, an HMAC key, and initial counter value for a session that is used for communication between the Xbox One console and the title server. To identify the key uniquely, a session identifier is also created. Keys should be unique for each Xbox One console (even if in the same session).

  1. Receive keys and share key material

The Key Distribution Webservice selects a title server (which may be spun up) and shares the symmetric key, HMAC key, initial counter value, and the session identifier with it. The title server responds with its IP address. The Key Distribution Webservice then responds to the client with the symmetric key, initialization vector, session identifier, and IP address of the title server.

  1. Establish symmetric encryption

The title on the Xbox One console then connects to the IP address of the title server through a UDP port, and uses the symmetric key and initial counter value for AES256 CTR encryption in a known handshake message. The initial handshake protocol should include the session identifier and/or the XSTS token for further validation of user information. If the session identifier, XSTS token, or handshake is incorrect (or encryption errors are encountered), the title server should disconnect the client. The initial handshake is also used to establish the starting internal sequence number for messages. (For details, see the following section, Message format and handling.)

Note CTR cipher mode is used for resilience against individual packet loss. CBC cipher mode can be used instead, but is not as loss-tolerant. A cipher block depends on the previous block, so the block immediately after a packet loss cannot be decrypted. For CBC mode it’s necessary to use a higher-level, reliable UDP flow to resend packets.

Message format and handling

To ensure replay protection and integrity, the recommended design uses the following message format.

Figure 3.  Recommended message format.

During the handshake, the client and title server each establish their initial message sequence number for messages. These initial sequence numbers should be randomized for additional security.

From this point forward, all messages contain increasing sequence numbers to protect against replay attacks. If any packet with a previously observed sequence number is encountered, it is discarded.

To protect message integrity, an HMAC of the message payload and sequence number is also created and included in the packet prior to encryption. Any packet with invalid HMAC is also discarded.

Note The preceding flow, message format and handling only shows high-level steps and design needed for secure communication. Title services must have an appropriate level of logging and be resilient to unauthorized or incorrect communication.

Security review

Any secure communication protocol needs to be reviewed and approved before it can be used to ensure confidentiality, integrity, and availability of the Xbox One console, your title, and third-party publisher services. The use of insecure socket definitions triggers this review requirement.

To start a security review, contact your developer account manager as early as possible and provide the following information:

For an example document, see Appendix C.

This information will be used during the security review to identify potential security issues. The review may also include selective code or packet format review. This additional review is performed as needed and managed through your developer account manager.

We highly recommend that you perform the security review early to avoid any delays due to the process. A pre-security review with ATG is also available and recommended to identify issues early on. It can be scheduled through your developer account manager.

Summary

When considering Xbox One network communication, always use secure communication methods: use Secure Sockets Layer for communication between Xbox One consoles, use HTTPS connections for web service communication, and use WebSockets over HTTPS for TCP connections. Do not use any custom security protocols for these cases.

UDP connections to title servers require a custom security protocol that needs to be reviewed prior to use. Make sure that you adhere to the recommended design guidance and approved cryptographic algorithms for this design. To avoid delays, schedule a security review as early as possible with your developer account manager.

Securing communication is critical to ensuring the confidentiality, integrity, and availability of the Xbox One console, Xbox Live Services, and third-party publisher services.

References

Appendix A: Insecure socket definition

Configuring the network manifest for insecure sockets

Configuring a title for custom network protection is very similar to configuring debug socket usage for developer scenarios. Instead of using the Send/ReceiveDebug socket usages, use the undocumented Send/ReceiveInsecure socket usages. The following network manifest snippet provides an example of socket descriptions with Send/ReceiveInsecure usages.

      <mx:SocketDescription Name="ConsoleSocket" SecureIpProtocol="Udp" BoundPort="7000">   
        <mx:AllowedUsages>
          <mx:SecureDeviceSocketUsage Type="Initiate" />
          <mx:SecureDeviceSocketUsage Type="SendInsecure" />
          <mx:SecureDeviceSocketUsage Type="ReceiveInsecure" />
       </mx:AllowedUsages>
      </mx:SocketDescription>
       
      <mx:SocketDescription Name="ServerSocket" SecureIpProtocol="Udp" BoundPort="7001">
        <mx:AllowedUsages>
          <mx:SecureDeviceSocketUsage Type="Accept" />
          <mx:SecureDeviceSocketUsage Type="SendInsecure" />
          <mx:SecureDeviceSocketUsage Type="ReceiveInsecure" />
        </mx:AllowedUsages>
      </mx:SocketDescription>

Do not specify other usages. Send/ReceiveGameData and Send/ReceiveChat indicate to the system that a SecureDeviceAssociation must be created prior to traffic flowing over the specified socket. Send/ReceiveDebug is not allowed in retail scenarios and will not be permitted in appxmanifests being submitted for certification.

Appendix B: Security testing

Fuzz testing

When using non-platform supported network parsers (such as anything other than HTTPS, IPsec, or Smooth Streaming), you must give careful attention to the data that is being parsed and how the title behaves if it were to receive incorrect or malformed data. In many instances, these types of behaviors can lead to logic flaws or buffer overruns, which could lead to code injection or execution.

To understand how a title behaves when it receives poorly formed data, we strongly encourage the use of Network Fuzzing. As a thought exercise, consider the title’s network traffic without any encryption or integrity protection.

Fuzzing is a security testing procedure leveraged by Microsoft that prevents a great number of security bugs and provides substantial return on investment for a developer. It is a process by which intentionally malformed data is sent to data parsing code. This can be done with both network and file parsers. It is especially helpful on network traffic that is sent unencrypted and without data integrity because this traffic is subject to tampering attacks.

While it is possible to write custom fuzzing software, both commercial and open source software projects such as the Peach Fuzzer can assist in this testing.

For more information about white-box fuzz testing, see Automated Penetration Testing with White-Box Fuzzing on MSDN. Fuzz testing is also a part of the Microsoft Secure Development Lifecycle.

Penetration testing

This type of testing (often referred to as a “pentest”) occurs when a security firm is engaged to identify weaknesses in a system or title. Depending on the data sensitivity, the type of cryptography (or lack thereof), and other design review factors, Microsoft may require a penetration test as part of certification.

Note The type of penetration tests requested from Microsoft are often more broad and more in depth than those required for industry standard certifications such as PCI-DSS. Therefore, industry certification pentests are rarely accepted as an acceptable substitute.

Typically, penetration testing is done by using the following methods:

Appendix C: Example security review document

The following section outlines a security review document that must be provided for all security reviews of custom protocols.

Protocol overview

The proposed protocol uses the following flow.

  1. Request keys

The Xbox One title instance starts by sending a RESTful request to the Key Distribution Webservice (through IXHR2). The request includes an XSTS token with the following claims: TitleID, PWID, and privileges.

  1. Verify client XSTS token

The Key Distribution Webservice uses the claims for authentication in the following way:

  1. Generate keys

If the user’s authentication succeeds, the Key Distribution Webservice generates an AES256 symmetric key, an HMAC key, and an initial counter value for a session that is used for communication between the Xbox One console and the title server. To identify the key uniquely, a session identifier is also created. Keys are unique for each Xbox One console (even if in the same session). All random values are created by using secure random APIs.

  1. *Receive keys and share key material *

The Key Distribution Webservice selects a target title server and shares the symmetric key, HMAC key, initial counter value and the session identifier with it. This communication is performed in the VPN of the local datacenter.

The title server responds with its IP address. The Key Distribution Webservice then responds to the client with the symmetric key, session identifier, initial counter value, and IP address of the title server.

  1. Establish symmetric encryption

The title on the Xbox One console connects to the IP address of the title server through UDP 7090 with the symmetric key, nonce, and a counter for AES256 CTR encryption and a known handshake message.

The initial handshake protocol includes a known start message, the session identifier, and the XSTS token. The XSTS token is validated to ensure the correct user is present.

If the session identifier, XSTS token, or handshake is incorrect (or encryption errors are encountered), the title server should disconnect the client.

Cryptographic details

Message format

The following message format is used:

During the handshake, the client and title server each establish their initial payload sequence number for messages. These initial payload sequence numbers are securely randomized.

A reliable UDP communication is implemented on the title level. A client acknowledges receipt of packets. A server will resend lost packets until they are acknowledged as received.

Message failure details

Protocol services

The following services are used for this protocol:

Protocol API usage

The following security-relevant APIs are used for this protocol: