平成31年度 春期 情報処理安全確保支援士試験 午後Ⅰ 問3｜手元で分解されるゲーム機——情報処理安全確保支援士で学ぶIoT認証トークンとTPM・セキュアブートの設計事例

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士
• 出典: 平成31年度 春期 情報処理安全確保支援士試験 午後1 問3
• 主なテーマ: IoT機器（家庭用ゲーム機）の認証連携、認証トークン、MACとディジタル署名の違い、クライアント認証、耐タンパ性、TPM、セキュアブート

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

セキュリティの世界では、サーバやネットワークの守りに注目が集まりがちです。しかしIoT機器（インターネットにつながるモノ。家電や産業機器、そして家庭用ゲーム機など）には、サーバにはない決定的な弱点があります。それは「利用者の手元に置かれ、ときに攻撃者の手で分解される」という前提です。

情報処理安全確保支援士の午後1で出題されたこの事例は、新しい家庭用ゲーム機の開発を舞台に、まさにこの「手元で物理的に攻撃される」前提に立ったセキュリティ設計レビューを描いています。設計リーダが描いた一見もっともらしい設計に、レビュー担当者が次々と穴を指摘していく——その対話を追ううちに、認証トークンの仕組み、MAC（メッセージ認証符号）とディジタル署名の本質的な違い、TPMと耐タンパ性、そしてセキュアブートという、組込み・IoTセキュリティの中核概念が立体的に見えてきます。

この記事を読むと、なぜ共通鍵を使うMACでは「鍵を知っている人なら誰でも偽造できる」のか、なぜディジタル署名なら「作れるのは認証サーバだけ」に限定できるのか、そして汎用部品に鍵を置く危うさと、それを救うTPM・セキュアブートの考え方が分かります。受験者には認証と暗号技術の頻出論点が、製品を開発・販売する立場の管理者には「出荷した瞬間から製品はユーザの手元で物理攻撃にさらされる」という現実が、セキュリティインシデントを未然に防ぐ事例として伝わるはずです。

インシデントの概要

舞台は、IoT機器を製造・販売する従業員3,000名の企業、V社です。V社は新しい家庭用ゲーム機「ゲーム機V」の発売を計画していました。設計を担当するのは開発部で、設計リーダは開発部のHさんです。

このゲーム機Vは、昔ながらの「ソフトを差し込んで遊ぶ」据置機とは仕組みが違います。利用者は、ゲーム機Vとゲームプログラムの利用権を購入し、ゲーム機Vからインターネット越しに、クラウド上のゲームサーバで動くゲームプログラムを利用します。ゲーム機Vは画面とコントローラを備えた端末で、実際のゲーム処理はクラウド側で行われ、コントローラの操作はリアルタイムにクラウドへ送られ、ゲーム画面が手元に返ってくる——いわゆるクラウドゲーミングに近い構成です。

クラウド側には、V社が用意したクラウドサービス「クラウドV」があり、その中に二種類のサーバが置かれます。一つは利用者の認証を担う認証サーバ。もう一つは、ゲームプログラムが実際に動くゲームサーバです。しかもゲームサーバは一社が運営するのではなく、複数のゲームプログラム開発会社がそれぞれ自社のゲームサーバを立ち上げ、その上で一つまたは複数のゲームプログラムを動かす、という形をとります。この「認証サーバ」「ゲームサーバ」「ゲーム機V」の三つを合わせて、ゲームシステムVと呼びます。

ここで重要なのは、登場人物が一枚岩ではないという点です。ゲームサーバを運用するのは、V社の社員ではなく、社外のゲームプログラム開発会社のサーバ管理者です。つまり「同じシステムの中に、必ずしも全面的に信頼しきれない関係者がいる」という構造になっています。この事例のドラマは、この一点から生まれます。

V社では、製品を世に出す前の設計工程でセキュリティレビューを実施することにしていました。レビューを担当するのは、セキュリティ部のNさんです。Hさんが描いた設計図を前に、NさんとHさんの対話劇が始まります。

何が起きたのか

まず、Hさんが設計した認証の流れを追いましょう。利用者がゲームを遊ぶとき、ゲーム機Vはこう動きます。

利用者は、ゲーム機Vに利用者IDとパスワードを入力します。ゲーム機Vの通信プログラムは、これを認証サーバの利用者認証プログラムに送ります。認証サーバは、登録された利用者情報（利用者ID、パスワードのハッシュ値、ニックネームなど）と照らして本人確認を行い、その利用者がアクセスできるゲームプログラムIDの一覧を返します。利用者が遊びたいゲームを選ぶと、そのゲームプログラムIDを認証サーバに送り、認証サーバは「認証トークン」と、そのゲームプログラムごとに固有のURLを発行して返します。ゲーム機Vはこの認証トークンを持って、URLが指すゲームサーバのゲームプログラムにアクセスします。ゲームプログラムが認証トークンを検証して問題なければ、ゲーム画面が返ってくる——これが基本の流れです。なお、最初の利用者認証や、ゲームサーバへの認証トークン提示で認証に失敗した場合は、ゲーム機Vに認証エラー画面が送られます。

ここで鍵になるのが「認証トークン」です。トークン（通行証のような短いデータ。本人確認済みであることをサーバ間で受け渡すために使う）には、認証サーバのFQDN（サーバの正式なドメイン名）、利用者ID、そしてMAC（Message Authentication Code、メッセージ認証符号。データが改ざんされていないことと、正しい相手が作ったことを確認するための短い検証値）が格納されています。このMACは、認証サーバのFQDNと利用者IDに対して、ハッシュ関数を共通鍵と組み合わせて使って生成されます。

ゲームサーバ側のゲームプログラムは、受け取った認証トークンのMACを検証し、さらにFQDNが確かに認証サーバのものであることを確認できたときだけ、認証成功としてゲーム画面を返します。トークンが改ざんされていればMACの検証に失敗するので、不正なトークンははじける——Hさんの設計は、一見すると筋が通っています。

しかし、ここに最初の落とし穴があります。MACの生成に使う共通鍵は、ゲームシステムV全体でたった一つだけ。そしてその共通鍵は、ゲームサーバ管理者がゲームプログラムに設定するのです。つまり、社外のゲームサーバ管理者が、その共通鍵の中身を知ってしまう構造になっていました。

レビューの場で、Nさんは静かに切り出します。「現状の認証トークンの設計には、二つの問題があります」。

一つ目の問題は、認証トークンに格納される情報が足りないことでした。現在のトークンには、どのゲームプログラム向けに発行されたのかという情報が入っていません。そのため、ゲームプログラムA用に正規に発行された認証トークンを、そのままゲームプログラムBに提示しても、認証に成功してしまうのです。攻撃者がゲームプログラムのURLさえ知ることができれば、自分が購入していないゲームプログラムまで遊べてしまう。Nさんは、この問題への対策を検討するようHさんに求めます。

二つ目の問題は、もっと根が深いものでした。「認証トークンを、ゲームサーバ管理者が不正に生成できてしまうこと」です。本来、認証トークンを発行できるのは認証サーバだけであるべきです。ところが、MACの生成には共通鍵が使われ、その共通鍵をゲームサーバ管理者が知っている。検証する側と同じ鍵で生成もできてしまうため、悪意あるゲームサーバ管理者は、認証サーバを通さずに自分で有効な認証トークンをでっち上げられるのです。これでは、購入していないゲームプログラムの利用や、クラウドV上のリソースの不正利用につながりかねません。

HさんはMACの仕組みを救おうと提案します。「ゲームプログラムごとに別の共通鍵を使う設計にしてはどうでしょうか」。一見、被害範囲を区切れそうな案です。しかしNさんは首を振ります。「それでは対策として不十分です」。共通鍵を分けても、ゲームサーバ管理者は自分が運用するゲームサーバに設定された共通鍵を知っています。だから、その鍵で守られる範囲——自身が管理するゲームサーバ上で動く全ゲームプログラム分の認証トークンは、依然として偽造できてしまうのです。問題の本質は「共通鍵では、検証できる人が生成もできてしまう」という、対称鍵そのものの性質にありました。

そこでHさんが核心に触れます。「MACではなく、ディジタル署名を使えば対策になりますか」。Nさんは頷きます。「はい。そうすれば、ゲームサーバ管理者が認証トークンを不正に生成しようとしても、ゲームプログラムでの検証に失敗します」。

ディジタル署名は、公開鍵暗号という仕組みを使います。署名を作るための秘密鍵と、署名を検証するための公開鍵をペアで用意し、秘密鍵は持ち主だけが握り、公開鍵は誰に渡してもかまいません。Hさんは設計を具体化します。「認証サーバで公開鍵と秘密鍵の鍵ペアを生成し、公開鍵をゲームサーバに配布しておく。認証サーバが秘密鍵を使って認証トークンに署名を付け、ゲームプログラムでは公開鍵を使って署名を検証する」。こうすれば、署名を作れるのは秘密鍵を持つ認証サーバだけ。公開鍵を持つゲームサーバ管理者は「検証はできるが生成はできない」状態になり、トークンの偽造を断てます。Nさんは「問題ありません」と認めました。

認証トークンの議論が一段落すると、Nさんは次の論点に進みます。「不正な機器から、認証サーバやゲームサーバへのアクセスをどう防ぎますか」。Hさんは「クライアント認証を使います」と答えます。クライアント認証とは、サーバが利用者の正当性を確認するだけでなく、接続してくる機器側の正当性もサーバが確認する仕組みです。ゲーム機Vには、機器ごとに発行されたクライアント証明書と、それに対応する秘密鍵(鍵C)が格納されており、各サーバとの通信時にこの証明書を使って「正規のゲーム機Vである」ことを示します。

ところがNさんは、ここで最も鋭い指摘を放ちます。「もし、ゲーム機V内のクライアント証明書と鍵Cが、攻撃者のPCから不正に使えてしまったら、そのPCから各サーバに接続できてしまいます。さらに、コントローラの操作情報を改ざんして送り、ゲームを有利に進めることも考えられます。——クライアント証明書と鍵Cは、ゲーム機Vのどこに格納するつもりですか」。

Hさんは答えます。「鍵Cを含めた全てのデータは、搭載するSSD（Solid State Drive、記憶装置）に格納します。広く流通しているSSDを使う予定です」。

Nさんの表情が変わります。「それでは問題があります」。たとえ専用OSにまったく脆弱性がなかったとしても、攻撃者がゲーム機Vを一台購入し、中の汎用SSDを物理的に取り外して自分のPCにつなげば、専用OSを一切改ざんすることなく、SSDの中身——クライアント証明書も鍵Cも——を直接読み出せてしまう、というのです。ゲーム機Vは「PCに接続しても外部ストレージとして認識されず、内部データを直接読み出せない」設計でした。しかしそれはあくまで「ゲーム機Vを通して」の話。広く流通する汎用SSDなら、機器から抜き取ってPCに差せば、その保護は意味をなしません。IoT機器が手元に置かれ、分解されるという前提を突いた指摘でした。

Hさんは対策を求めます。「どう対策すればいいでしょうか」。Nさんが示したのが、TPM（Trusted Platform Module、機器に組み込む専用のセキュリティチップ）です。「TPMをゲーム機Vに搭載し、その内部に鍵Cを保存する方法があります。TPMは、内部構造や内部データを解析されにくい性質を備えているので、鍵CをTPM内に保存すれば、不正に読み取ることは困難になります」。この「内部構造や内部データの解析・改ざんを困難にする性質」こそ、耐タンパ性と呼ばれるものです。

さらにNさんは、もう一つの宿題を出します。ブートローダ（電源投入後、最初にOSを読み込んで起動させる小さなプログラム）や専用OSそのものが改ざんされれば、それもまたゲーム機Vの不正利用——たとえばコントローラの不正な操作情報の送信——につながります。「ブートローダと専用OSの改ざん対策についても検討してください」。Hさんは「分かりました。設計を見直します」と応じ、レビューはいったん終わります。

二度目のレビューで、Hさんは改ざん対策の設計を持ち込みました。考え方はこうです。ブートローダと専用OSのうち、起動時に実行されるファイルのハッシュ値（データの内容を要約した固定長の値。中身が少しでも変わると値も変わる）をあらかじめ計算し、「ハッシュ値リスト」として作っておきます。これをゲーム機Vへの専用OS導入時に一緒に保存しておきます。起動時にファイルが実行される順番は、あらかじめ決まっています。

起動の瞬間には、CRTM（Core Root of Trust for Measurement、測定の信頼の起点となる、改ざんが困難な起動コード)から処理を始めます。CRTMはまずブートローダのハッシュ値を計算し、その値がハッシュ値リストの中に存在することを確認できたらブートローダを実行します。次にブートローダが、専用OSの最初に実行されるファイルのハッシュ値を計算し、リストに存在することを確認して実行します。以後、後続のファイルについても「計算→リストと照合→一致すれば実行」を繰り返し、専用OSが起動します。もしハッシュ値がリストの中に見つからないファイルがあれば、それは改ざんされたと判定し、起動処理を中止する——改ざんされた機器は、そもそも立ち上がらないようにする設計です。

Nさんは最後の確認をします。「その仕組みは、ハッシュ値リストが守られていることが前提ですね。ハッシュ値リスト自体が改ざんされてしまえば、攻撃者は改ざんしたファイルのハッシュ値をリストに書き加えるだけで、不正なファイルを正規のものとして実行させられます。——ハッシュ値リストは、どうやって保護しますか」。Hさんは、その保護方法を説明します。Nさんは「それであれば、改ざんされたファイルが実行される危険性は低い」と納得しました。こうして設計レビューを終えたゲーム機Vは、クラウドVの準備が整ったのち、無事に発売されたのでした。