戦国IT - 情報処理技術者試験の過去問対策サイト
お知らせお問い合わせ料金プラン

情報処理安全確保支援士 2019年 春期 午後103


IoT機器の開発に関する次の記述を読んで、設問1~3に答えよ。

 V社は、IoT機器を製造・販売している従業員数3,000名の会社である。家庭用ゲーム機(以下、ゲーム機Vという)の発売を予定しており、設計を開発部が担当している。設計リーダは、開発部のHさんである。利用者はゲーム機Vとゲームプログラムの利用権を購入し、ゲーム機Vからゲームサーバ上のゲームプログラムを利用する。複数のゲームプログラム開発会社が、それぞれ複数のゲームプログラムを開発し、販売する予定である。開発部が設計したゲーム機V、認証サーバ及びゲームサーバ(以下、三つを併せてゲームシステムVという)の構成を図1に、構成要素とその概要を表1に示す。
情報処理安全確保支援士試験(令和1年度 午後1 問03 図01)
情報処理安全確保支援士試験(令和1年度 午後1 問03 表01)
 ゲームを行う際は図2の認証フローで利用者の認証が行われる。
情報処理安全確保支援士試験(令和1年度 午後1 問03 図02)
 認証トークンには、認証サーバのFQDN、利用者ID及びMAC(Message Authentication Code)が格納される。①MACは、認証サーバのFQDNと利用者IDに対して、ハッシュ関数を共通鍵と組み合わせて使用し、生成する。共通鍵は、ゲームシステムV全体で一つの鍵が使用され、ゲームサーバ管理者がゲームプログラムに設定する。図2の5.では、ゲームプログラムによる認証トークンのMACの検証が成功し、かつ、FQDNが確かに認証サーバのものであることが確認された場合だけ、認証が成功し、図2の6.でゲームプログラムからゲーム画面が送信される。   〔セキュリティレビューの実施〕  認証トークンが認証サーバ以外で不正に生成されると、購入していないゲームプログラムを利用されたり、クラウドV上のリソースを不正に利用されたりするおそれがある。そこで仮に認証サーバ以外で認証トークンを生成されたとしてもゲームプログラムでは検証に失敗することが求められる。また、利用者がコントローラの不正な操作情報をゲーム機Vから送信することによって、ゲームを有利に進めるといったことも防ぐ必要がある。  V社では、システム設計にセキュリティ上の問題がないか、製品の設計工程でセキュリティレビュー(以下、レビューという)を実施することになっており、ゲームシステムVはセキュリティ部のNさんがレビューを担当することになった。次は、NさんがゲームシステムVのレビューを行った時の、Hさんとの会話である。    Nさん:現状の認証トークンの設計には二つの問題があります。一つ目の問題は、現在の設計では認証トークンに格納される情報が不足しているということです。情報が不足していることによって、ゲームプログラムA用の認証トークンがゲームプログラムBにおいても認証に成功してしまうので、攻撃者がゲームプログラムのURLを知ることができれば、購入していないゲームプログラムも利用できてしまいます。②この問題への対策を検討してください。  Hさん:分かりました。  Nさん:二つ目の問題は、③認証トークンをゲームサーバ管理者が不正に生成できてしまうことです。  Hさん:その問題への対策としては、ゲームプログラムごとに別の共通鍵を利用するという設計はどうでしょうか。  Nさん:それでは対策として不十分です。④その設計にしたとしても、不正にゲームプログラムが利用できる認証トークンをゲームサーバ管理者が生成できてしまいます。  Hさん:MACではなく、ディジタル署名を利用すれば対策になりますか。  Nさん:はい。そうすればゲームサーバ管理者が認証トークンを不正に生成したとしても、ゲームプログラムで検証が失敗します。  Hさん:では、aで公開鍵と秘密鍵の鍵ペアを生成し、bをゲームサーバに配布しておきます。acを使って認証トークンに署名を付加し、ゲームプログラムではbを使って署名の検証を行います。  Nさん:それで問題ありません。次に、不正な機器から認証サーバとゲームサーバへのアクセスをどのようにして防ぐのか教えてください。  Hさん:クライアント認証を使います。  Nさん:ゲーム機V内のクライアント証明書とそれに対応する秘密鍵(以下、鍵Cという)が攻撃者のPCから不正に使用できると、そのPCから各サーバに接続されてしまいます。さらに、コントローラの操作情報を改ざんして送信することによって、ゲームを有利に進めることも考えられます。クライアント証明書と鍵Cはゲーム機Vのどこに格納しますか。  Hさん:鍵Cを含めた全てのデータは、搭載するSSD(Solid State Drive)に格納します。搭載するSSDは、広く流通しているものです。  Nさん:それでは問題がありますね。現状の設計では、専用OSに脆弱性が存在しなかったとしても、⑤攻撃者がゲーム機Vを購入すれば、専用OSを改ざんせずに、ゲーム機V内のクライアント証明書と鍵CをPCなどから不正に使用できます。  Hさん:どのように対策したらいいでしょうか。  Nさん:TPM(Trusted Platform Module)をゲーム機Vに搭載し、TPM内に鍵Cを保存するという方法があります。TPMは、⑥内部構造や内部データを解析されにくい性質を備えているので、TPM内に鍵Cを保存すれば不正に読み取ることは困難になります。また、ブートローダ又は専用OSの改ざんはゲーム機Vの不正利用につながります。例えば、コントローラの不正な操作情報を送信されるおそれがあります。そのため、ブートローダ及び専用OSの改ざん対策についても検討してください。  Hさん:分かりました。設計を見直します。   〔ブートローダ及び専用OSの改ざん対策〕  2回目のレビューでは、ブートローダ及び専用OSの改ざん対策について確認した。次は、その時のHさんとNさんの会話である。
 Hさん:ブートローダ及び専用OSの改ざんに備えた対策として、ブートローダ又は専用OSが改ざんされていると判定されたときは、ゲーム機Vの起動処理を中止するようにしました。ブートローダ及び専用OSの改ざん対策の処理の流れを図3に示します。
情報処理安全確保支援士試験(令和1年度 午後1 問03 図03)
 Nさん:処理の流れは分かりました。ハッシュ値リストが保護されていないと、改ざんされたファイルが実行されるおそれがありますが、どのように対策していますか。  Hさんは、⑦ハッシュ値リストを保護するための方法を説明した。  Nさん:それであれば、改ざんされたファイルが実行される危険性は低いですね。    その後、クラウドVの準備が整い、ゲーム機Vが発売された。

設問1

本文中の下線①に該当する方式はどれか。該当する方式を解答群の中から選び、記号で答えよ。
解答群  ア:CBC-MAC  イ:CMAC  ウ:CSR  エ:HMAC  オ:MD5  力:RC4

模範解答

解説

解答の論理構成

  1. 【問題文】では「①MACは、認証サーバのFQDNと利用者IDに対して、ハッシュ関数を共通鍵と組み合わせて使用し、生成する」と記載されています。
  2. “ハッシュ関数”と“共通鍵”を組み合わせて MAC を生成する代表的な方式は HMAC(Keyed-Hash Message Authentication Code)です。
  3. 解答群を確認すると、ハッシュ関数+鍵を用いる方式は「エ:HMAC」だけです。
  4. よって該当する方式は「エ」となります。

誤りやすいポイント

  • 「ア:CBC-MAC」「イ:CMAC」はブロック暗号をベースにした MAC であり、ハッシュ関数は使いません。説明文に“ハッシュ関数”とある時点で除外すべきです。
  • 「オ:MD5」はハッシュ関数そのものです。“共通鍵と組み合わせて”という条件を満たしません。
  • 「力:RC4」はストリーム暗号、「ウ:CSR」は証明書署名要求であり、どちらも MAC 方式ではありません。

FAQ

Q: HMAC はどんなハッシュ関数でも使えますか?
A: 基本的に SHA-256 など安全なハッシュ関数であれば利用できます。MD5 など脆弱なハッシュ関数は避けるのが一般的です。
Q: CBC-MAC と HMAC は何が違いますか?
A: CBC-MAC はブロック暗号の CBC モードを応用した MAC、HMAC はハッシュ関数を鍵付きで利用した MAC です。前者はブロック暗号依存、後者はハッシュ関数依存という違いがあります。
Q: ハッシュ関数と共通鍵を組み合わせるだけなら自作でも良いのでは?
A: 自作は推奨されません。HMAC は理論的に安全性が検証され、実装上の手順も標準化されています。安全性と相互運用性の面から既存の HMAC を採用すべきです。

関連キーワード: HMAC, MAC, ハッシュ関数、共通鍵暗号、認証トークン

設問2〔セキュリティレビューの実施〕について、(1)〜(6)に答えよ。

(1)本文中の下線②について、対策として認証トークンに追加する必要がある情報を、15字以内で答えよ。

模範解答

ゲームプログラムID

解説

解答の論理構成

  1. 現在の認証トークンに含まれる情報は
    「認証サーバのFQDN、利用者ID及びMAC」だけであると明記されています。
    ――【問題文引用】「認証トークンには、認証サーバのFQDN、利用者ID及びMAC(Message Authentication Code)が格納される。」
  2. その結果として、Nさんは
    「ゲームプログラムA用の認証トークンがゲームプログラムBにおいても認証に成功してしまう」
    という欠点を指摘しています。
    ――【問題文引用】「ゲームプログラムA用の認証トークンがゲームプログラムBにおいても認証に成功してしまう」
  3. トークンを特定のゲームプログラム専用にするには、各プログラムを一意に示す情報を追加しなければなりません。
    ――【問題文引用】「各ゲームプログラムには、固有のゲームプログラム ID が付与される。」
  4. したがって、認証トークンに不足している情報は「ゲームプログラムID」であり、これを追加することで別プログラムへの誤用を防止できます。

誤りやすいポイント

  • 「URL¹)」を追加すれば十分と考えてしまう
    → URLは変更される可能性があり、また既に認証フロー4.で別送されているため、検証情報として適切ではありません。
  • 「購入情報全体」を入れようとする
    → 必要なのはプログラムを一意に識別する最小限の情報であり、過剰な情報はトークンサイズや管理負荷を増やします。
  • 「FQDNがあるから大丈夫」と誤認する
    → FQDNはサーバ識別用であり、ゲームプログラム識別にはなりません。

FAQ

Q: ゲームプログラムIDを追加した後、MACの計算はどうなりますか?
A: MACは「認証サーバのFQDN・利用者ID・ゲームプログラムID」を連結したデータに対して同じ共通鍵で計算します。これにより改ざん防止効果が維持されます。
Q: ゲームプログラムIDの代わりにハッシュ値を入れても良いですか?
A: 可能ですが、結局はゲームプログラムIDをハッシュ化しただけで意味は同じです。読みやすさと運用を考慮し、IDそのものを使う設計が一般的です。
Q: ゲームプログラムIDを追加してもURLが漏れたら攻撃されませんか?
A: URLを知られても、正しいゲームプログラムIDを含むトークンを生成できなければ認証は通りません。MACによりIDの改ざんも検出できます。

関連キーワード: MAC, 認可、ハッシュ関数、デジタル署名、トークン管理

設問2〔セキュリティレビューの実施〕について、(1)〜(6)に答えよ。

(2)本文中の下線③について、その原因となるゲームサーバの仕様を、30字以内で述べよ。

模範解答

ゲームサーバに認証サーバと同じ共通鍵を保存する。

解説

解答の論理構成

  1. 認証トークンの真正性は「①MACは、認証サーバのFQDNと利用者IDに対して、ハッシュ関数を共通鍵と組み合わせて使用し、生成する」とあるように共通鍵で担保しています。
  2. ところが「共通鍵は、ゲームシステムV全体で一つの鍵が使用され、ゲームサーバ管理者がゲームプログラムに設定する」と記載されており、ゲームサーバ側にも同一の共通鍵が置かれる設計です。
  3. ゲームサーバ管理者はこの共通鍵を保持しているため、下線③「認証トークンをゲームサーバ管理者が不正に生成できてしまう」が発生します。
  4. したがって原因となる仕様は「ゲームサーバに認証サーバと同じ共通鍵を保存する」です。

誤りやすいポイント

  • 「共通鍵をゲームプログラムに“設定する”」だけでは、物理的に保存されると理解せず見落とす。
  • 共通鍵がゲームプログラムごとに同じか異なるかを論点と勘違いし、保存場所の問題であることに気付かない。
  • “MAC方式だから脆弱”と短絡的に判断し、鍵の管理プロセスが問題である点を抜かす。

FAQ

Q: 共通鍵を暗号化して格納すれば問題は解決しますか?
A: いいえ。管理者は復号手段も持つため、依然として不正生成が可能です。
Q: 共通鍵をプログラムにハードコードし読めなくすれば安全ですか?
A: 十分ではありません。実行バイナリから鍵を抽出されるリスクが残り、本質的対策になりません。
Q: MACの代わりにディジタル署名が推奨される理由は?
A: 秘密鍵を認証サーバだけに保持でき、ゲームサーバには公開鍵のみ配布すれば改ざん検出が可能だからです。

関連キーワード: 共通鍵、MAC, ディジタル署名、鍵管理、認証トークン

設問2〔セキュリティレビューの実施〕について、(1)〜(6)に答えよ。

(3)本文中の下線④について、その原因となる認証トークンの仕様を、20字以内で述べよ。また、不正に生成した認証トークンで利用できるゲームプログラムの範囲を、35字以内で述べよ。

模範解答

仕様:MACの生成に共通鍵を使用する。 範囲:自身が管理するゲームサーバ上で動作する全ゲームプログラム

解説

解答の論理構成

  1. 認証トークンの生成方法
    【問題文】には
    「①MACは、認証サーバのFQDNと利用者IDに対して、ハッシュ関数を共通鍵と組み合わせて使用し、生成する」
    とあり、さらに
    「共通鍵は、ゲームシステムV全体で一つの鍵が使用され」
    と記載されています。
    “ゲームシステムV全体で一つ”の「共通鍵」を使うため、鍵を知る者はだれでも正当な MAC を付与した認証トークンを作れます。
  2. ゲームサーバ管理者が鍵を入手できる経路
    表1には「ゲームサーバごとに発行されたサーバ証明書を格納している」とあるほか、会話中で
    「ゲームサーバ管理者がゲームプログラムに設定する」
    と述べられており、ゲームサーバ管理者は共通鍵を業務上入手できます。
  3. 仕様上の弱点
    MAC の生成に「共通鍵」を用いる仕様のままでは、ゲームサーバ管理者が自ら生成したトークンの MAC 検証に必ず成功します。これが下線④の原因です。
  4. 不正トークンで利用できる範囲
    N さんは
    「④その設計にしたとしても、不正にゲームプログラムが利用できる認証トークンをゲームサーバ管理者が生成できてしまいます」
    と明言しています。ゲームサーバ管理者が管理しているのは自サーバ上のゲームプログラムすべてです。したがって、生成したトークンは「自身が管理するゲームサーバ上で動作する全ゲームプログラム」で受け入れられます。

誤りやすいポイント

  • 共通鍵が「ゲームシステムV全体で一つ」なので他社サーバにも悪用できると誤解しやすいですが、管理者が操作できるのは自サーバのみです。
  • “トークンにゲームプログラムIDが含まれない”点を答えに入れてしまうミス。仕様として問われているのは鍵の扱いです。
  • 範囲を「全ゲームサーバ」まで広げてしまい、実際の権限範囲を超えて記述する誤答。

FAQ

Q: 共通鍵方式のまま鍵をプログラムごとに分けても効果が薄いのはなぜですか?
A: ゲームサーバ管理者は自プログラム用の鍵を当然入手しているため、その鍵でトークンを生成できるからです。
Q: 認証トークンにゲームプログラムIDを追加するだけでは十分ですか?
A: 鍵を保持する管理者が署名を付けられる限り、不正生成は防げないため不十分です。
Q: ディジタル署名に変更すると何が変わりますか?
A: 秘密鍵を認証サーバだけが保持し、公開鍵をゲームサーバに配ることで、管理者は署名を生成できなくなります。

関連キーワード: 共通鍵、MAC, 認証トークン、ディジタル署名、アクセス制御

設問2〔セキュリティレビューの実施〕について、(1)〜(6)に答えよ。

(4)本文中のacに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群  ア:共通鍵  イ:ゲーム機V  ウ:ゲームサーバ  エ:公開鍵  オ:認証サーバ  力:秘密鍵

模範解答

a:オ b:エ c:カ

解説

解答の論理構成

  1. 【問題文】には
    “Hさん:では、aで公開鍵と秘密鍵の鍵ペアを生成し、bをゲームサーバに配布しておきます。acを使って認証トークンに署名を付加し、ゲームプログラムではbを使って署名の検証を行います。”
    とあります。鍵ペアを生成・署名を行う主体は、ゲームサーバ管理者から独立していて信頼できる必要があります。
  2. 直前の会話でNさんは
    “二つ目の問題は、③認証トークンをゲームサーバ管理者が不正に生成できてしまう”
    と指摘しています。したがって、鍵ペアを保有し署名を行う主体はゲームサーバ管理者ではなく“認証サーバ”であるべきです。
    a=“オ:認証サーバ”
  3. 署名の検証は多数のゲームサーバで行われるため、配布すべきものは非秘密情報である“公開鍵”です。
    b=“エ:公開鍵”
  4. 署名を付加する際に用いる鍵は公開してはならない“秘密鍵”です。
    c=“カ:秘密鍵”
以上より
a:オ b:エ c:カ が成立します。

誤りやすいポイント

  • “ゲームサーバが鍵ペアを作ればよい”と考えてしまう
    → それでは③の問題(ゲームサーバ管理者が不正に生成)を解決できません。
  • “配布するのは秘密鍵”と思い込む
    → 秘密鍵を配布すると漏えいリスクが高まり署名の信頼性が崩壊します。
  • “共通鍵でも良いのでは”と混同する
    → 共通鍵方式では鍵を共有する相手が増えるほど漏えい確率が上がり、③の対策になりません。

FAQ

Q: 認証サーバが署名主体になると、ゲームサーバごとに鍵を変える必要はありますか?
A: いいえ、単一の認証サーバが秘密鍵を保護していれば、ゲームサーバ側は同一の公開鍵で検証できます。必要に応じて鍵更新ポリシを設ければ十分です。
Q: 公開鍵をゲーム機にも配布して検証させる方法は?
A: 証明書として組み込み、ファームウェア更新時に差し替えます。改ざん検出のためブート時検証(図3の仕組み)と併用することで安全に保てます。
Q: 共通鍵MACとディジタル署名の主な違いは?
A: MACは鍵を共有する全員が生成も検証も可能ですが、ディジタル署名は“秘密鍵で生成・公開鍵で検証”という非対称性を持ち、発行者の一意性を保証できます。

関連キーワード: ディジタル署名、公開鍵暗号方式、秘密鍵管理、認証トークン

設問2〔セキュリティレビューの実施〕について、(1)〜(6)に答えよ。

(5)本文中の下線⑤について、どのようにするとクライアント証明書と鍵CをPCなどから使用可能にしてしまうことができるか。攻撃者が使用前に行う必要があることを、25字以内で具体的に述べよ。

模範解答

SSDを取り出し、PCなどにつなげる。

解説

解答の論理構成

  1. クライアント証明書と秘密鍵Cの保存場所
    • Hさんは「鍵Cを含めた全てのデータは、搭載するSSD(Solid State Drive)に格納します」と述べています。
  2. SSD の汎用性
    • 同じく Hさんは「搭載するSSDは、広く流通しているものです」と明言しています。よって一般的な PC でも物理的に接続可能です。
  3. OS を改ざんせずに証明書を盗む方法
    • Nさんは下線⑤で「攻撃者がゲーム機Vを購入すれば、専用OSを改ざんせずに、ゲーム機V内のクライアント証明書と鍵CをPCなどから不正に使用できます」と指摘しています。
  4. ⑤を満たす具体的手順
    • ゲーム機Vを開封し、内蔵 SSD を取り外し、市販の SATA-USB 変換アダプタなどで PC に接続すれば、OS の改ざんを伴わずにファイルシステムへ直接アクセスできます。
  5. 以上から、設問が求める「攻撃者が使用前に行う必要があること」は「SSDを取り出し、PCなどにつなげる」となります。

誤りやすいポイント

  • 「ゲーム機Vを分解する」とだけ書くと“何を取り出すのか”が不明確で失点しやすいです。
  • OS の脆弱性を突くなど論点がズレた回答を書いてしまうケースがありますが、設問は“専用OSを改ざんせずに”という条件付きです。
  • SSD を PC に接続して初期化する、クローンを作るなど作業後の行為を詳述し過ぎると焦点がぼやけます。

FAQ

Q: 「外部ストレージとして認識されない」とあるが SSD を抜けば読めるのか?
A: はい。ゲーム機Vに装着された状態では認識されませんが、物理的に取り外して PC に直結すれば通常の SSD と同様にアクセス可能です。
Q: “取り外し”と“分解”はどちらを使うべき?
A: 設問は「クライアント証明書と鍵CをPCなどから使用可能にする方法」を聞いており、鍵が入った「SSD」を抜き PC に接続することが核心です。表現は「SSDを取り出し、PCに接続」などが適切です。
Q: TPM を導入すればこの攻撃は防げる?
A: TPM に鍵Cを格納すれば、SSD から鍵を読み取ることはできず、物理的取り外し攻撃への耐性が高まります。

関連キーワード: 物理攻撃、ストレージ抽出、クライアント証明書、秘密鍵保護、TPM

設問2〔セキュリティレビューの実施〕について、(1)〜(6)に答えよ。

(6)本文中の下線⑥について、この性質を何というか。10字以内で答えよ。

模範解答

耐タンパ性

解説

解答の論理構成

  1. 問題文は、TPM に対して「⑥内部構造や内部データを解析されにくい性質」と述べています。
  2. セキュリティ分野では、外部からの物理的・論理的な解析や改ざんを困難にする性質を一般に「耐タンパ性(tamper resistance)」と呼びます。
  3. したがって、TPM が備える上記の性質を端的に表す用語として「耐タンパ性」が適切です。

誤りやすいポイント

  • 「暗号化機能」や「鍵保護機能」と回答してしまう。どちらも TPM の特徴ではありますが、問いは“性質”を尋ねており幅広い攻撃耐性を示す言葉が求められています。
  • 「改ざん検知」や「改ざん防止」と答える。改ざん検知は耐タンパ性の一部要素ですが、解析そのものを困難にするというニュアンスが不足しています。
  • TPM = IC チップという連想から「セキュアエレメント」と記述する。ハードウェア名称ではなく、そのハードウェアが持つ性質を答える必要があります。

FAQ

Q: 耐タンパ性とは具体的にどのような手段で実現されますか?
A: 樹脂封止による回路の解析防止、電圧・温度・クロック異常検出回路による自己破壊、メモリ内容の暗号化など、多層的な物理防御と攻撃検知機能を組み合わせて実現します。
Q: 耐タンパ性が高いだけで秘密鍵を絶対に守れますか?
A: 100%の安全を保証するわけではありません。高度な物理解析やサイドチャネル攻撃を受ける可能性は残るため、運用面の対策やソフトウェアの防御と組み合わせることが重要です。
Q: 一般的なストレージ暗号化と耐タンパ性はどう違いますか?
A: ストレージ暗号化はデータを暗号化して読み出しを困難にしますが、ハードウェア自体の分解・解析を前提にしていません。耐タンパ性はハードウェアレベルでの物理的解析や改ざんを困難にする性質を指します。

関連キーワード: TPM, 耐タンパ性、物理攻撃、秘密鍵保護、改ざん防止

設問3

本文中の下線⑦について、保護するための適切な方法を本文中の用語を使って、25字以内で具体的に述べよ。

模範解答

ハッシュ値リストをTPMに保存する。

解説

解答の論理構成

  1. 脅威の確認
    • Nさんは「ハッシュ値リストが保護されていないと、改ざんされたファイルが実行されるおそれがあります」と指摘しています。
    • すなわち、ハッシュ値リスト自体を改ざんできれば、ブートローダや専用OSが改ざんされても検知を回避できるというリスクが存在します。
  2. 保護手段に求められる要件
    • ハッシュ値リストを外部から書き換え・読み取りしにくい形で格納することが必要です。
    • その条件を満たすデバイスとして、本文ではTPMの特性が示されています。
  3. TPMの適合性
    • Nさんは「TPM(Trusted Platform Module)をゲーム機Vに搭載し、TPM内に鍵Cを保存するという方法があります」と提案し、さらに「TPMは、⑥内部構造や内部データを解析されにくい性質を備えている」と説明しています。
    • この特性は鍵Cだけでなく、他の重要データの保護にも利用でき、ハッシュ値リストにもそのまま適用可能です。
  4. 結論
    • 改ざんを防ぐには、ハッシュ値リストをTPMに格納して物理的・論理的に保護するのが最適です。
    • よって解答は「ハッシュ値リストをTPMに保存する。」となります。

誤りやすいポイント

  • 「SSDに暗号化して保存する」など一般的なストレージ暗号化を挙げると、ハードウェア的な抜き取り攻撃を防ぎきれず不十分です。
  • 「署名付きでハッシュ値リストを配布する」のみでは、改ざんされたリストごと入れ替えられる恐れが残ります。
  • TPMを“鍵管理専用”と誤解し、ハッシュ値リストを入れられないと思い込むケースがありますが、実際にはセキュアストレージ領域として利用できます。

FAQ

Q: TPMに入れるのは鍵情報だけではないのですか?
A: いいえ。TPMは耐タンパ性を利用したセキュアストレージ領域を提供しており、鍵以外の小容量データ(ハッシュ値リストなど)も安全に保持できます。
Q: ハッシュ値リストをTPMに保存すると起動時間が遅くなりませんか?
A: TPMから読み出すのは起動時に限定され、データ量も小さいため、実運用で問題になる程の遅延は発生しません。
Q: ハッシュ値リストをTPMに保存すれば、ファイル改ざん検知は完全ですか?
A: 改ざん検知の前提は「計算したハッシュ値」と「改ざんされていないハッシュ値リスト」の比較です。TPMで後者を保護しても、前者を計算するコード(CRTMなど)が改ざんされては意味がないため、多層的なセキュアブート設計が重要です。

関連キーワード: TPM, セキュアブート、ハッシュ値、耐タンパ性、改ざん検知
戦国ITクイズ機能

\ せっかくなら /

情報処理安全確保支援士
クイズ形式で学習しませんか?

クイズ画面へ遷移する

すぐに利用可能!

©︎2026 情報処理技術者試験対策アプリ

このサイトについてプライバシーポリシー利用規約特商法表記開発者について