9. 独自サーバー
本章では、NEX 対応ゲームソフトにおいて、任天堂が運営するゲームサーバーとは別に独自のゲームサーバーを使用する際に必要な情報や注意事項を扱います。
9.1. 独自サーバーのサービス内容と申請
9.1.1. 独自サーバーで禁止されるサービス
9.1.1.1. NAT トラバーサル機能
P2P 通信を行うゲームは、基本的に NEX による NAT トラバーサル機能を利用してください。 独自の NAT トラバーサル機能、例えば UPnP などを使用すると、他の NEX 対応ゲームソフトとの整合性が取れず、ユーザーに混乱を与えてしまいます。
弊社は多数の無線 LAN アクセスポイントと NEX の NAT トラバーサル機能との相性を検証し、弊社ホームページで動作確認済み機種一覧を公開しています。 ユーザーサポートを円滑に行うためにも、この旨ご理解ください。
9.1.2. 利用申請
技術面での検証、ロットチェック、ユーザーサポート部門への通知を目的として、使用する独自サーバーについての情報を OMAS で申請していただきます。
弊社での申請内容の確認後、独自サーバーやゲームソフトの実装で必要になる認証トークン鍵やキーハッシュ値、(必要性に応じて)SSL サーバー証明書を発行させていただきます。
9.1.3. SSLサーバー証明書
独自サーバーとの通信で SSL を利用される場合、そのサーバーに設定する SSL サーバー証明書を、弊社の独自認証局にて発行することができます。 発行を希望される場合は OMAS にて申請し、CSR ファイルを弊社窓口までお渡しください。
弊社発行の SSL サーバー証明書には、次の特徴があります。
- サーバー証明書の有効期間を最大限に設定していますので、証明書の定期更新は不要です。
- 発行費用はいただきません。
- Opera や Internet Explorer、Firefox などのブラウザにはこの認証局は搭載されていませんので、パソコンからも接続されるサーバーには利用できません。
VeriSign、CyberTrust、RSA などの一般商用認証局や、貴社独自の認証局を利用いただいても構いません。 商用認証局を利用される場合は、ルート証明書を製品に搭載するためのライセンスと、認証局の都合による変更の可能性にご注意ください。 またどちらの場合においても、証明書の鍵長は RSA2048bit 以上としてください。 署名アルゴリズムは SHA-1 以上を必須、SHA-256 を推奨とします。
9.1.4. ロットチェックに関する注意点
弊社でのロットチェックは、製品環境のサーバーを利用して行う場合があります。 マスター提出前にはサーバー環境を整え、ロットチェック期間中のメンテナンスは極力お控えください。 もし都合により製品環境のサーバーが利用できない場合は、マスター提出の際にお知らせください。
また、続編タイトルなどで製品環境のサーバーを利用するのが難しい場合は、製品環境と同等のサーバーを、別途用意するようにしてください。
9.2. 独自サーバーとの通信
9.2.1. 任天堂認証サーバーでの認証
任天堂認証サーバーは、接続元のクライアントの正当性確認などを行うサーバーです。 各種サーバーサービスを利用する前に必ず認証サーバーに接続してクライアントの認証を行う必要があります。
また、独自サーバーが、任天堂認証サーバーが認証したクライアントであることを検証できるように、認証サーバーは、独自サーバー用認証トークンを発行する機能があります。
NEX では、ゲームサーバーにログインする関数や認証トークンを取得する関数の内部で認証サーバーによる認証処理を行っていますので、開発者がこの処理を単独で実装する必要はありません。
9.2.2. 任天堂ゲームサーバーと独自サーバーを併用する場合の流れ
最初に、NEX の NgsFacade::LoginAndRequestAuthenticationToken() を使って、任天堂認証サーバーでの認証、独自サーバー用認証トークンの取得、ゲームサーバーへの接続までをまとめて行います。 このとき、OMAS にて利用申請が承認されたときに発行されるキーハッシュを使用します。
その後、独自ゲームサーバーに接続する際に取得した認証トークンを送信し、独自サーバー側でこれを検証すること(「 9.2.5. 独自サーバーでの認証トークンの検証と利用 」参照)で、正当なクライアントであるかを確認してから、独自サーバーの機能を利用することができます。 認証トークンの送信方法は規定しませんが、パケットの盗聴などによる認証トークンの不正利用を防ぐため、なるべく通信経路を暗号化してください。
また、独自サーバーでは、認証トークンの検証にあたって、認証トークンに含まれる認証トークンの生成日時を使って、24 時間有効とします。 クライアントでは、認証トークンを有効期限中に使い回すことで認証サーバーへのアクセスを省略することができますが、有効期限切れで認証トークンの再取得が必要になった場合は、IndependentServer::RequestAuthenticationToken() を使って、認証トークンを再取得してください。 なお、認証トークンをセーブデータなどに保存して使いまわすことは禁止です。
9.2.3. 独自サーバーのみを利用する場合の流れ
最初に、NEX の IndependentServer::RequestAuthenticationToken() を使って、任天堂認証サーバーでの認証、認証トークンの取得までをまとめて行います。 このとき、OMAS にて利用申請が承認されたときに発行されるキーハッシュを使用します。
その後の独自サーバーとの接続は、任天堂ゲームサーバーと独自サーバーを併用する場合( 9.2.2. )と同様です。
9.2.4. セキュリティ
認証トークンの仕組みをご利用いただくことで、認証サーバーを経由したクライアント以外からの接続を拒否することができるようになり、独自サーバー側のセキュリティをある程度確保することができます。
さらに、ニンテンドー 3DS 側のセキュリティも確保するために、通信パケットの改ざんや、貴社の独自サーバーに成り済ました偽装サーバーとの通信を防ぐようにしてください。 これを実現するには、独自サーバーが送信するデータに電子署名(RSA 署名・HMAC 値など)を付加し、受信時にデータの完全性を確認する、もしくは独自サーバーとの通信に HTTPS プロトコルを採用し、通信開始時にサーバー証明書の正当性を確認するなどの方法が有効です。
9.2.5. 独自サーバーでの認証トークンの検証と利用
認証トークンを検証することで、任天堂認証サーバーによる認証処理が行われたクライアントからの接続であることを確認することができます。 サーバー間認証のような制限は設けていませんので、この認証トークンを利用しなくても独自サーバーへの接続は技術的には可能です。 しかし、独自サーバー自体のセキュリティを確保するためには、認証トークンをご利用ください。
認証トークンの利用については、CTR ガイドラインの独自サーバーの項目を必ずご確認ください。
認証トークンは、下記の各値を埋め込んだ文字列を AES を使ってゲームソフトごとに異なる認証トークン鍵で暗号化したものです。 NEX で取得できる認証トークンは、これを更に特殊な Base64 でエンコードした文字列になります。 このBase64は、通常使用される「+」「/」「=」の代わりに「.」「-」「*」が使用されます。
\u\(プリンシパルID)\f\(フレンドコード)\s\(サーバー環境)\t\(生成日時)\h\(ハッシュ値)
項目名 | 説明 |
---|---|
プリンシパルID | 先行 0 なしの数値。最大 10 桁。 |
フレンドコード | 先行 0 ありの数値。12 桁固定。 |
サーバー環境 | 英数 2 文字固定。開発環境は”D1 ~ D9”、製品環境は”L1 ~ L9”、ロットチェック環境は”S1 ~ S9”のいずれかになります。万一これら以外の環境情報が通知された場合にも、製品環境の独自サーバに影響を与えないように考慮してください。 |
生成日時 | UNIX タイムスタンプ。 |
ハッシュ値 | 暗号化前の文字列の”\u”から”(生成日時)”までの SHA-1 ハッシュ値を hex 表記した先頭 8 文字(英字は小文字)。 |
独自サーバーは、クライアントから受信した認証トークンを復号し、復号後の文字列について、フォーマットやハッシュ値が正しいか、トークン生成日時が 24 時間以内か、などを検証することで、クライアントの正当性を確認します。 復号や各値の取り出し方法などの詳細は、NEX に含まれる認証トークン確認用サンプルプログラムを参照してください。 また、トークンの有効期限の確認のために、独自サーバーのシステム時間は、NTP 等を利用して定期的に調整してください。
9.3. 独自サーバー環境の分離
独自サーバーを設置する場合、サービス開始後にも一般ユーザーに影響を与えずに検証・開発をおこなえる環境を、製品環境とは別に用意することを強く推奨します。 ニンテンドー 3DS 上で動くアプリケーションの接続する独自サーバー環境を切り替えるには、次のような手段が考えられます。
9.3.1. ダミー DNS サーバー
独自サーバーのホスト名を製品環境とは別の IP アドレスに解決する DNS サーバーを設置し、ニンテンドー 3DS のネットワーク接続設定もしくはアクセスポイントに、その DNS サーバーを設定する方法です。 同じ設定の DNS サーバーを第三者が設置した場合、製品実機からでも同様に接続先を切り替えられることに注意してください。
9.3.2. サービスロケーター
全環境共通の独自サーバーで一度認証トークンを復号し、記載された認証サーバー環境によって接続先を振り分ける方法です。 通常、開発機材は開発環境、製品実機は製品環境の認証サーバーから認証トークンを取得します。 認証サーバーの環境と連動せずに、より細かく独自サーバー環境を切り替えたい場合には他の方法を併用する必要があります。
9.4. 複数の認証サーバー環境への対応
独自サーバーは、複数の認証サーバー環境が発行した認証トークンが届く可能性を考慮する必要があります。認証トークンを発行した認証サーバー環境は、復号した認証トークンに含まれる英数 2 文字の環境名によって、以下のとおりに区別することができます。
- D1 ~ D9: 開発環境
- L1 ~ L9: 製品環境
- S1 ~ S9: ロットチェック環境
- J1 ~ J9: 互換性検証環境
異なる認証サーバー間では、プリンシパル ID が重複する可能性があります。 独自サーバーでユーザを識別する場合、プリンシパル ID だけでなく、環境名とプリンシパル ID をあわせてユニークな ID として扱ってください。 ダミー DNS サーバーやサービスロケーターによって異なる環境に所属するユーザからのアクセスが混ざらない運用をおこなう場合であっても、万一の事故に備えて、異なる環境のプリンシパル ID を混同することがないようにしてください。 アプリ開発者が通常の開発環境を使用している限り、環境名としては常に同じものが返ります。例えば開発環境の D1 ~ D9 の数値部分が時期等によって変わることはありません。 製品環境も同様で、製品環境の L1 ~ L9 の数値部分が変わることはありません。従って、環境名とプリンシパル ID をセットで使用することでユーザー識別情報とすることが可能です。 開発環境で通常使用される環境名は D1 で、製品環境で通常使用される環境名は L1 です。ユーザー及びアプリ開発者の環境ではこれら2つの環境名が返ってきますが、任天堂が確認の為に使用する環境で J2 等、D1, L1 以外の環境名が返ってくる可能性があります。従って、どのような環境名が返ってきた場合にも動作するように設計してください。
注意
認証サーバーの環境は、将来的もしくは一時的に増設される可能性があります。そうした場合などに万一想定外の環境が通知されても、製品環境の独自サーバーに影響を与えないように考慮してください。
9.4.1. 任天堂による検証への対応
弊社では、アプリケーションのマスターアップ前におこなうロットチェックのほか、システムアップデートのリリース前に既存タイトルの互換性検証をおこなうことがあります。 独自サーバーに弊社の検証でロットチェック環境や互換性検証環境からアクセスをしてはならない場合や、アクセスするために設定が必要な場合(例えば、弊社の DNS サーバーに独自サーバーのレコードを追加する必要がある等)は、ロットチェック提出書類にその旨を明記してください。