情報処理安全確保支援士試験の午後問題には、情報セキュリティに関する最新の動向を反映した題材が採用されています。
キーワードに加え、設計やインシデント対応能力をシミュレーションできる良い学びの場ですので、情報処理安全確保支援士試験合格はもちろん、情報処理安全確保支援士となった後も能力向上のために学習していきましょう。
今回は、「IoT機器」を題材にした「IoT機器と複数サーバ間での認証連携」を解説していきます。
「IoT機器と複数サーバ間での認証連携」とは
IoTの世界では、「モノ」側のハードウェアでは極力、小型化され省電力が要求される場合が多いため、最低限必要な機能を実行するためだけのリソースに制限されます。
したがって、ネットワークを介して収集、アクセスされる情報に対して、「モノ」側では制御が困難であり、バックエンドにあるシステムやクラウドサービス側での制御や管理が必要となる場合が多くなります。
その一つとして利用者などの認証機能があり、IoT機器が接続するサーバが複数ある場合に、それらを連携して動作させるために認証連携が必要になってきます。
平成31年度春期情報処理安全確保支援士試験での「IoT機器と複数サーバ間での認証連携」
「IoT機器」を題材に、サーバ間での認証連携、及びIoT機器への物理的な不正アクセスへの対策について出題されました。
それでは「IoT機器と複数サーバ間での認証連携」の問題となった部分を見ていきましょう。
V社は、IoT機器を製造・販売している従業員数3,000名の会社である。家庭用ゲーム機（以下、ゲーム機Vという）の発売を予定しており、設計を開発部が担当している。設計リーダは、開発部のHさんである。利用者はゲーム機Vとゲームプログラムの利用権を購入し、ゲーム機Vからゲームサーバ上のゲームプログラムを利用する。複数のゲームプログラム開発会社が、それぞれ複数のゲームプログラムを開発し、販売する予定である。開発部が設計したゲーム機V、認証サーバ及びゲームサーバ（以下、三つを併せてゲームシステムVという）の構成を図１に、構成要素とその概要を表１に示す。
ゲームを行う際は図２の認証フローで利用者の認証が行われる。
認証トークンには、認証サーバのFQDN、利用者ID及びMAC（Message Authentication Code）が格納される。①MACは、認証サーバのFQDNと利用者IDに対して、ハッシュ関数を共通鍵と組み合わせて使用し、生成する。共通鍵は、ゲームシステムV全体で一つの鍵が使用され、ゲームサーバ管理者がゲームプログラムに設定する。図２の5.では、ゲームプログラムによる認証トークンのMACの検証が成功し、かつ、FQDNが確かに認証サーバのものであることが確認された場合だけ、認証が成功し、図２の6.でゲームプログラムからゲーム画面が送信される。
［セキュリティレビューの実施］
認証トークンが認証サーバ以外で不正に生成されると、購入していないゲームプログラムを利用されたり、クラウドV上のリソースを不正に利用されたりするおそれがある。そこで仮に認証サーバ以外で認証トークンを生成されたとしてもゲームプログラムでは検証に失敗することが求められる。また、利用者がコントローラの不正な操作情報をゲーム機Vから送信することによって、ゲームを有利に進めるといったことも防ぐ必要がある。
V社では、システム設計にセキュリティ上の問題がないか、製品の設計工程でセキュリティレビュー（以下、レビューという）を実施することになっており、ゲームシステムVはセキュリティ部のNさんがレビューを担当することになった。次は、NさんがゲームシステムVのレビューを行った時の、Hさんとの会話である。
Nさん：現状の認証トークンの設計には二つの問題があります。一つ目の問題は、現在の設計では認証トークンに格納される情報が不足しているということです。情報が不足していることによって、ゲームプログラムA用の認証トークンがゲームプログラムBにおいても認証に成功してしまうので、攻撃者がゲームプログラムのURLを知ることができれば、購入していないゲームプログラムも利用できてしまいます。②この問題への対策を検討してください。
Hさん：分かりました。
Nさん：二つ目の問題は、③認証トークンをゲームサーバ管理者が不正に生成できてしまうことです。
Hさん：その問題への対策としては、ゲームプログラムごとに別の共通鍵を利用するという設計はどうでしょうか。
Nさん：それでは対策として不十分です。④その設計にしたとしても、不正にゲームプログラムが利用できる認証トークンをゲームサーバ管理者が生成できてしまいます。
Hさん：MACではなく、ディジタル署名を利用すれば対策になりますか。
Nさん：はい。そうすればゲームサーバ管理者が認証トークンを不正に生成したとしても、ゲームプログラムで検証が失敗します。
Hさん：では、（a）で公開鍵と秘密鍵の鍵ペアを生成し、（b）をゲームサーバに配布しておきます。（a）が（c）を使って認証トークンに署名を付加し、ゲームプログラムでは（b）を使って署名の検証を行います。
Nさん：それで問題ありません。
設問2（1）本文中の下線②について、対策として認証トークンに追加する必要がある情報を、15字以内で答えよ。
正解：ゲームプログラムID
設問2（2）本文中の下線③について、その原因となるゲームサーバの仕様を、30字以内で述べよ。
正解：ゲームサーバに認証サーバと同じ共通鍵を保存する。
設問2（3）本文中の下線④について、その原因となる認証トークンの仕様を、20字以内で述べよ。また、不正に生成した認証トークンで利用できるゲームプログラムの範囲を、35字以内で述べよ。
正解：
仕様：MACの生成に共通鍵を使用する。
範囲：自身が管理するゲームサーバ上で動作する全ゲームプログラム
設問2（4）本文中の（a）〜（c）に入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア 共通鍵 イ ゲーム機V ウ ゲームサーバ
エ 公開鍵 オ 認証サーバ カ 秘密鍵
正解：
（a）：オ （b）：エ （c）：カ
【出典：情報処理安全確保支援士試験 平成31年度春期午後1問3（一部、省略部分あり）】
設問２（１）
問題文から、認証トークンには認証サーバのFQDN、利用者ID及びMACが格納されています。
この情報のままだと、「ゲームプログラムA用の認証トークンがゲームプログラムBにおいても認証に成功してしまうので、攻撃者がゲームプログラムのURLを知ることができれば、購入していないゲームプログラムも利用できてしまう」という問題あるというものです。
図２の認証フローを見て確認します。
「4.認証トークンとゲームプログラムのURL」で得られた認証トークンをゲームプログラムに送信することでゲームプログラムが利用できます。
「1.利用者IDとパスワード」と「2.アクセス可能なゲームプログラムIDの一覧」で、利用者IDが利用できるプログラムが限定できますが、このやり取り以外の何らかの方法で他のゲームプログラムのURLを知ることができれば、購入していないゲームプログラムも利用できてしまいます。
この問題の解決策を考えます。
ゲームプログラムは、ゲーム機Vがアクセスしてきたときに、URLの他にゲームプログラムを特定する情報を検証できればいいことに気づくと思います。
これには、図１、図２の説明の中にある「ゲームプログラムID」が最適です。
設問２（２）
認証トークンが不正に生成できてしまうとはどういうことでしょう。
認証トークンは、「認証サーバのFQDN、利用者ID及びMAC」が格納され、MACは「認証サーバのFQDNと利用者IDに対して、ハッシュ関数を共通鍵と組み合わせて使用し、生成」とあります。
これらの情報のうち、「共通鍵」以外は容易に入手可能なものです。
では「共通鍵」はどうかというと、「共通鍵は、ゲームシステムV全体で一つの鍵が使用され、ゲームサーバ管理者がゲームプログラムに設定する」とあり、ゲームサーバ管理者が入手している状態です。
したがって、ゲームサーバ管理者が不正に認証トークンを生成できてしまいます。
ゲームサーバの仕様における原因としては、「ゲームサーバに認証サーバと同じ共通鍵を保存する。」になります。
設問２（３）
ゲームプログラムごとに別の共通鍵を利用したとしても、ゲームサーバ管理者がゲームプログラムごとの共通鍵を知り得ることには変わりはありません。
根本的に、MACの生成に共通鍵を使用することが問題の原因となります。
次に不正に生成した認証トークンで利用できるゲームプログラムの範囲ですが、ゲームサーバ管理者が管理できる範囲であることは容易に想像できるでしょう。
ゲームサーバ管理者が管理できる範囲は、表１にある通り、自身が管理するゲームサーバですので、その中の全てのゲームプログラムとなります。
設問２（４）
ディジタル署名の鍵生成場所と検証方法について問われています。
鍵生成場所については、ゲームシステムVの構成要素であるゲーム機V、ゲームサーバ、認証サーバ が候補となります。
ゲーム機Vは利用者側にあるもので、鍵生成には適しません。また、ゲームサーバはゲーム管理者が運用しており、認証トークンを検証する側のため、鍵生成には適しません。
したがって、鍵生成は認証サーバで実施します。
次に、検証方法ですが、ディジタル署名では送信者側で秘密鍵を保管して署名する際に利用し、受信者側で公開鍵で検証に使用します。