9. Independent Servers

This chapter provides necessary information about using independent game servers that are separate from the servers managed by Nintendo in NEX-compatible game software, and describes common problems to watch out for.

9.1. Applying for Services on Independent Servers

9.1.1. Services Prohibited on Independent Servers

9.1.1.1. NAT Traversal Feature

In general, use the NAT traversal feature provided by NEX for games that use peer-to-peer (P2P) communication. When using independent NAT traversal functionality, such as UPnP, a lack of consistency with other NEX-compatible game software causes confusion for users.

Nintendo has verified compatibility between several wireless LAN access points and the NAT traversal feature of NEX, and has published a list of devices that have been tested for compatibility on our website. Understand this material to facilitate user support.

9.1.2. Applying to Use Servers

To study the technical issues and notify the user support and Lotcheck departments, applications for use of independent servers must be submitted through OMAS.

After Nintendo has verified the details of your application, we will issue an authentication token key and key hash value, and (if necessary) an SSL server certificate that enable you to implement an independent server and your game software.

9.1.3. SSL Server Certificates

If you use SSL to communicate with an independent server, Nintendo's proprietary certification authority can issue an SSL certificate for use on that server. If you want a certificate, apply on OMAS and send a CSR file to Nintendo.

An SSL server certificate issued by Nintendo has the following properties.

  • Because the server certificate is set to the maximum possible expiration date, there is no need to renew it periodically.
  • There is no charge for issuing a certificate.
  • Browsers such as Opera, Internet Explorer, or Firefox do not have this certificate authority registered, so you cannot connect to the server from a personal computer.

You may also use a commercial certificate authority, such as VeriSign, CyberTrust, or RSA in addition to Nintendo's proprietary certificate authority. If you are using a commercial certificate authority, note that the license for a root certificate intended for embedding in a product may change depending on the whims of the certificate authority. Whichever option you choose, use a certificate with an RSA key that is at least 2,048 bits in length. The signature algorithm must be SHA-1 or higher. SHA-256 is recommended.

9.1.4. Notes About Lotcheck

Lotcheck at Nintendo may be performed using a production environment server. Set up the server environment before submitting your master, and be stringent about doing maintenance during the Lotcheck period. If it is impossible to use a production environment server for some reason, please notify Nintendo when submitting your master.

Also, in the event that it is difficult to use a production environment server for some reason, such as for a sequel title, prepare a separate server.

9.2. Communication With Independent Servers

9.2.1. Authentication on the Nintendo Authentication Server

The Nintendo authentication server verifies the validity of clients that are trying to connect. You must connect to the authentication server and validate clients before using server services.

The Nintendo authentication server can also issue authentication tokens for independent servers to use in ensuring that the clients have been verified by the Nintendo certificate server before allowing them to connect.

Because NEX performs authentication processing by means of the authentication server, which uses functions for getting authentication tokens or logging in to the game server, there is no need for developers to implement this functionality themselves.

9.2.2. Process for Linking-up the Nintendo Game Server and Independent Servers

First, use the NEX NgsFacade::LoginAndRequestAuthenticationToken function to authenticate on the Nintendo authentication server, get the authentication token for the independent server, and then connect to the game server. Use the key hash that was issued when the usage application was approved in OMAS.

Next, transmit the authentication token that was acquired for connecting to the independent game server, and verify that this client is valid by checking the token on the independent server. (For more information, see Section 9.2.5 Authentication and Usage of Authentication Tokens on an Independent Server.) After verification, you can use the independent servers. Although there are no specific requirements for how to transmit the authentication token, to prevent misuse of the authentication token by means such as packet sniffing, make sure to encrypt the communication pathway as much as possible.

When verifying authentication tokens on an independent server, use the token creation time included in that authentication token and set it to 24-hour time. Clients can accelerate their access to the authentication server by using an authentication token for as long as it is still effective. After that token has expired, you may use the IndependentServer::RequestAuthenticationToken function to get a new token. It is prohibited to save and use authentication tokens in save data.

9.2.3. Procedure for Using Only the Independent Server

First, use NEX's NgsFacade::LoginAndRequestAuthenticationToken function to authenticate on the Nintendo authentication server, get the authentication token for the independent server, and then connect to the game server. Use the key hash that was issued when the usage application was approved in OMAS.

After that, connecting to an independent server is the same as using the Nintendo authentication server in conjunction with an independent server. (For more information, see the previous section.)

9.2.4. Security

By using the authentication token system, the servers are able to ignore connection requests that do not come through the authentication server, and the independent server is able to guarantee a certain level of security.

To further assure security on the Nintendo 3DS, also try to prevent communication with fake servers that impersonate your company's independent servers, or packet forging. Some effective methods include adding a digital signature (such as an RSA signature or HMAC value) to packets sent by the independent server, verifying the completeness of data as it is received, and verifying the server's certificate when first connecting, and then using the HTTPS protocol for communication with the independent server.

9.2.5. Authentication and Usage of Authentication Tokens on an Independent Server

You can verify that connections are from clients that have been authenticated by the Nintendo authentication server by verifying the authentication token. Because there is no restriction on authentication between servers, it is technically possible to connect to an independent server even without using these authentication tokens. However, to protect the security of the independent server itself, use an authentication token.

For information about using authentication tokens, be sure to check the independent server section in the CTR Guidelines.

The authentication token is a string including the following values, which are encrypted with an AES key that is different for each piece of game software. Authentication tokens that you can get with NEX are strings that are further encoded in a particular way using Base64. This Base64 uses the symbols '.', '-', and '*' in place of the usual symbols of '+', '/', and '='.

Code 9.1 Format of Authentication Tokens

\u\(Principal ID)\f\(friend code)\s\(server environment)\t\(generation date and time)\h\(hash value)
Table 9.1. Values Included in Authentication Tokens for Use in Independent Servers
Name Description
Principal ID Numeric value without a leading 0. Maximum of 10 digits.
Friend code Numeric value with a leading 0. Fixed at 12 digits.
Server environment 2 character fixed alphanumeric string. This value is either D1 through D9 for the development environment, L1 through L9 for the production environment, or S1 through S9 for the Lotcheck environment. Make sure that notifications of environment information other than these do not affect your independent server in the production environment.
Generated date and time UNIX time stamp.
Hash value The leading 8 characters of the SHA-1 hash value of the unencrypted string of "\u" to "generated date and time," as written in hexadecimal with alphabetic characters in lowercase.

The independent server decrypts the authentication token received from the client, and then checks the validity of the client by validating the hash value and the format of the decrypted string, in addition to checking whether the token was generated within the past 24 hours. For more information about decryption and extraction of various values, see the sample program for verifying authentication tokens that is included in NEX. To verify the expiration period of tokens, use the system time of the independent server and periodically adjust it using NTP or a similar protocol.

9.3. Separating Independent Server Environments

When setting up an independent server, Nintendo highly recommends that you provide an environment for testing and development that is separate from the production environment so that the typical user is not affected by development and testing once you start providing service. The following procedure is conceivable for switching the independent server environment that an application running on the Nintendo 3DS connects to.

9.3.1. Dummy DNS Server

You can set up a DNS server that resolves the hostname of the independent server into a different IP address than the production environment, and then configure that DNS server in Nintendo 3DS network settings or in the access point. Note that if a third party has set up a DNS server with the same settings, you can similarly switch the IP address you connect to even from a retail system.

9.3.2. Service Locator

You can assign different access points based on the specified authentication server environment by decrypting an authentication token once on a shared independent server for all environments. Usually, development hardware gets an authentication token from the development environment authentication server, and retail hardware gets an authentication token from the production environment authentication server. This method must be used along with another method if you want to perform more intricate switching between independent server environments without linking to an authentication server.

9.4. Supporting Multiple Authentication Server Environments

The independent server must take into account the possibility that authentication tokens generated by multiple authentication servers may be received. The authentication server issuing the authentication token can be distinguished from other authentication servers as follows based on a 2-character alphanumeric value included in the decrypted authentication token.

  • D1 through D9: Development environment
  • L1 through L9: Production environment
  • S1 through S9: Lotcheck environment
  • J1 through J9: Compatibility verification environment

Principal IDs on different authentication servers may conflict. To identify a user on an independent server, be sure to use a unique ID based on a combination of the authentication server environment and the principal ID, instead of just the principal ID. Just in case a problem occurs, make sure that you do not mix principal IDs from different environments, even if you use a dummy DNS server or service locator to ensure there is no access from users belonging to different environments. As long as application developers always use the same development environment, the same environment name is returned. For example, the D1 through D9 values for the development environment do not change based on time or other parameters. Similarly, the L1 through L9 values for the production environment never change. As a result, using the environment name along with a principal ID provides enough information to uniquely identify any user. D1 is the environment name usually used for the development environment. L1 is the environment name usually used for the production environment. These two server names are returned when using the user and application developer environments. However, environment names other than D1 and L1 such as J2 (the environment Nintendo uses for compatibility testing) may also be returned. Your independent server must be designed to be able to handle any environment name that may be returned.

Warning

The number of authentication server environments may increase in the future, either temporarily or permanently. Make sure that notifications of unexpected environments do not affect your independent server in the production environment.

9.4.1. Support for Testing by Nintendo

In addition to the Lotcheck performed before an application master ROM is uploaded, Nintendo tests compatibility with existing titles before releasing a system update. Make sure to clearly specify in your Lotcheck submission documents whether to prevent access to your independent server from the Lotcheck environment or the compatibility testing environment during Nintendo's testing or whether special settings need to be configured to access your independent server (such as a record for the independent server needs to be added to Nintendo's DNS server).


CONFIDENTIAL