平成31年春 午後Ⅰ 問3 設問2(1)について教えてください。
https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt8000000ddiw-att/2019h31h_sc_pm1_qs.pdf

認証トークンにはゲームプログラムを識別する機能がないため、
ゲームプログラムIDを格納する必要があるとあります。
認証トークンはゲームを購入したユーザーに
ゲームタイトル毎に支給されると考えました。

認証トークンには以下情報が格納されています。
・認証サーバのFQDN
・利用者ID
・MAC

ゲームプログラムのURLを知ることができれば購入していない
ゲームを利用できるというのがわかりませんでした。

図2の認証において、購入情報は認証サーバが保持しているため、
「2.アクセス可能なゲームプログラムIDの一覧」
に購入していないタイトルは表示されない為、認証できないと思いました。

本問はゲーム機への不正行為（チート行為）対応です。
通常の利用では起きないような事象を、不正行為（チート行為）によって起こされた
場合を検討しています。

>認証トークンにはゲームプログラムを識別する機能がないため、
>ゲームプログラムIDを格納する必要があるとあります。
>認証トークンはゲームを購入したユーザーに
>ゲームタイトル毎に支給されると考えました。
図2の段階では認証トークンに含まれているのは
・認証サーバのFQDN
・利用者ID及びMAC
です。ゲームタイトルに関する情報は含まれていません。

>ゲームプログラムのURLを知ることができれば購入していない
>ゲームを利用できるというのがわかりませんでした。
仮にゲームプログラムのURLが仮に
(h)ttps://game.xxx.org/game007/
だとします。この場合、用意に
(h)ttps://game.xxx.org/game006/
(h)ttps://game.xxx.org/game008/
などの連番からの規則性が推測されてしまいます。
別の例として、ネットの情報で特定のゲームのURLが広く共有されて
しまう可能性も考えられます。

>図2の認証において、購入情報は認証サーバが保持しているため、
>「2.アクセス可能なゲームプログラムIDの一覧」
>に購入していないタイトルは表示されない為、認証できないと思いました。
不正行為（チート行為）により、「アクセス可能なゲームプログラムの一覧」が
変更されてしまう可能性があります。その点も考慮せねばなりません。

pix様

ご回答ありがとうございます。

本問はチート行為を想定しているのですね。
例えばゲームプログラムのURLがわかれば
ゲーム機Vがなくても
パソコンからサイトにアクセスして
違法なツールでゲームをプレイすることや
「アクセス可能なゲームプログラムの一覧」が
書き換えられてしまうということがあり得るのですね。

ではディジタル署名を採用しても、認証サーバの
秘密鍵が盗まれた場合はどうなるのか？
と思いました。
それはゲームのチートではないですし、
そんなことを言い出せば、キリがないということでしょうか。

>ではディジタル署名を採用しても、認証サーバの
>秘密鍵が盗まれた場合はどうなるのか？
>と思いました。
>それはゲームのチートではないですし、
>そんなことを言い出せば、キリがないということでしょうか。
はい。キリがないとういうか、今回のテーマから逸脱してしまいます。
秘密鍵の窃取は認証サーバへの不正侵入です。
そうなるとゲームプログラム関係なく、サーバへの不正侵入対策の
検討になります。

pix様

ご回答ありがとうございます。
理解しました。
ゲームのチート行為はゲームに関する
URLや認証トークンを対象に考えるのですね。

追加で教えてください。
攻撃者がゲームプログラムのURLを知った場合の対策として
なぜ認証トークンにゲームプログラムIDを追加することが有効なのでしょうか。
攻撃者がゲームプログラムのURLを知ることができるのであれば、
認証トークン内のゲームプログラムIDを
読み取ることもできるのでは？と思いました。

前提として認証トークンは物理的なデバイスであり、
以下情報が格納されていて、通常の利用法ではMACのみが
表示され、その他の値はクラッキングしないと確認できないという
理解でよいでしょうか。
・認証サーバのFQDN
・利用者ID及びMAC

>前提として認証トークンは物理的なデバイスであり、
>以下情報が格納されていて、通常の利用法ではMACのみが
>表示され、その他の値はクラッキングしないと確認できないという
>理解でよいでしょうか。
>・認証サーバのFQDN
>・利用者ID及びMAC
ここでいうトークンとはソフトウェア的な短い変数のことです。
多要素認証などに利用されるハードウェアトークンではありません。

認証トークンにゲームプログラムIDを格納していない場合、ゲームのURLがわかって
しまうと、認証トークンを利用して、ユーザーが購入していないゲームプログラムを
起動されてしまいます。

認証トークンにゲームプログラムIDを格納することにより、ゲーム起動時に
ゲームサーバのゲームプログラムが認証トークン内のゲームプログラムIDをチェックし、
一致したときのみゲームを起動するようになります。

pix様

ご回答ありがとうございます。

>ここでいうトークンとはソフトウェア的な短い変数のこ>とです。
>多要素認証などに利用されるハードウェアトークンでは>ありません。
短い変数(パスワード)を生成するツールということでしょうか。
調べましたが、トークンには
ハードウェアトークンとソフトウェアトークンがあるのでそう考えました。

また図2の認証の
4.「認証トークンとゲームプログラムのURL」に
おいてサーバがゲーム機Vに
短い変数とゲームプログラムURLを送るということでしょうか。

>短い変数(パスワード)を生成するツールということでしょうか。
>調べましたが、トークンには
>ハードウェアトークンとソフトウェアトークンがあるのでそう考えました。
トークンとは変数そのものです。パスワードというよりもチケットに近いです。
多要素認証などで用いられるハードウェアトークンとはツールというよりも
ハードウェアで生成されたトークンという意味です。

>また図2の認証の
>4.「認証トークンとゲームプログラムのURL」に
>おいてサーバがゲーム機Vに
>短い変数とゲームプログラムURLを送るということでしょうか。
はい。その認識であっています。

この投稿は投稿者により削除されました。(2024.03.18 11:12)

pix様

ご回答ありがとうございます。
トークンは変数そのものなのですね。

では、認証サーバのFQDNと利用者ID及びMACから
変数を作る為、「トークン内に格納する」という
表現になるのでしょうか。

その場合、解答の「ゲームプログラムID」を格納するとは、認証サーバのFQDNと利用者ID及びMACに
加えて、ゲームプログラムIDから変数を作る
ということでしょうか。

また、図2の「5.認証トークン」は
具体的にユーザ側が何の値をサーバに送るのでしょうか。
4.「認証トークンとゲームプログラムのURL」で
送られてきた変数をそのまま入力するでは
意味がないですし、送られてきた変数に対応する
変数をなんとかして用意する必要があると思いました。

>では、認証サーバのFQDNと利用者ID及びMACから
>変数を作る為、「トークン内に格納する」という
>表現になるのでしょうか。
はい。その認識でよいです。

>その場合、解答の「ゲームプログラムID」を格納するとは、認証サーバの
>FQDNと利用者ID及びMACに加えて、ゲームプログラムIDから変数を作る
>ということでしょうか。
はい。その認識でよいです。

>また、図2の「5.認証トークン」は具体的にユーザ側が何の値をサーバに送るの
>でしょうか。
>4.「認証トークンとゲームプログラムのURL」で送られてきた変数をそのまま
>入力するでは意味がないですし、送られてきた変数に対応する変数をなんとかして
>用意する必要があると思いました。
すみませんが、認証トークンに誤解があるようです。
認証トークンは許可するためのチケットのようなものです。一切変更を加えては
いけません。

スレ主様は認証トークンの発行元と送り先を誤解していませんか。
認証トークンの発行元：認証サーバ
認証トークンの送り先：ゲームサーバ
です。
認証サーバから発行された認証トークンをゲームサーバへ渡します。
ゲームサーバはその認証トークンが認証サーバから発行された本物あるかどうかを
確認します。

認証トークンまわりで不明点があるのであれば、
「体系的に学ぶ 安全なWebアプリケーションの作り方 第2版」（徳丸本）などを
参考にするのがよろしいかと思われます。

pix様

ご回答ありがとうございます。
ご丁寧に書籍まで紹介していただき感謝いたします。

すみません図2の「5.認証トークン」は
ゲーム機からゲームサーバプログラムに入力するものですね。
図を間違えて認識していました。

ではゲームプログラムAしか購入していないユーザが
ゲームプログラムBのURLを知った場合、
図2の認証フローでは以下理由で
ゲームプログラムBを遊ぶことはできないですよね。
・2.アクセス可能なゲームプログラムIDの一覧に
   ゲームプログラムAのみ表示される。
・4.認証トークンとゲームプログラムのURLでは
   ゲームプログラムAのURLが送られてくる。

ここで何らかのチート行為を
認証フロー内で行うのでしょうか。

以前、ご教授いただいた
URLをばら撒かれるというのはこの
認証フロー外のことですし
アクセス可能なゲームプログラムIDを
書き換えるのは、ゲームプログラムBの
URLがわかることで可能になるのでしょうか。

>ここで何らかのチート行為を
>認証フロー内で行うのでしょうか。
チート行為については以下のようなことが想定されます。
・認証トークンにゲームプログラムIDを含んでいないのは、脆弱性の一つであり
  将来的に何らかのチート行為という脅威が発生する元となっている
・チート行為として改造したファームウェアをゲーム機Vにインストールされる
  といった事態も想定される
などです。

端的にいうと
・認証トークンに脆弱性を残さない
・予期せぬチート行為によって、脆弱性を突かれる可能性がある
になります。

pix様

ご回答ありがとうございます。

>・認証トークンにゲームプログラムIDを含んでいないの>は、脆弱性の一つであり
>  将来的に何らかのチート行為という脅威が発生する元>となっている
>・チート行為として改造したファームウェアをゲーム機>Vにインストールされる

本問は認証フローの外にも思考をめぐらせて
そのようなリスクも考える必要があり
認証トークンにゲームプログラムIDを格納して
変数を生成することが必要なのですね。
理解しました。

ここまで丁寧にご教授いただきありがとうございます。