SC午後問題 事例解説シリーズ 第2弾：令和7年秋 午後 問2に学ぶ、暗号技術による機密性・完全性の担保

SC午後の記述式では、「暗号化しています」と書かれた事例ほど危険です。暗号は導入した時点で安全になる技術ではなく、どの方式を、どの利用モードで、どの鍵管理のもとで、どの範囲に適用したかで守れる性質が変わります。設問はまさにその差分を突いてきます。

シリーズ第2弾となる今回は、令和7年度 秋期（2025年10月）SC午後 問2のテーマである暗号技術による機密性と完全性の担保を取り上げます。第1弾のSaaSで起きる格納型XSSとファイルアップロードの検証不備と同様に、IPAの問題文はいっさい使わず、テーマだけを借りた架空事例で設問・回答例・採点ポイントまでを一気通貫で解説します。

なおSC試験は2026年度からCBT方式へ移行し、これまでの「午後試験」は科目Bという名称に変わります。本記事で扱う記述式の読み解き方と書き方は、名称が変わっても科目Bでそのまま通用します。

私がCIOを務めていた頃、拠点間をVPNで結んで通信を暗号化した時点で「これで情報は守られた」と安心していました。いま振り返ると、それは経路上の盗聴を防いだにすぎず、サーバに保管されたファイルそのものや、その暗号鍵の置き場所については何も担保していませんでした。この「暗号化イコール安全」という思い込みこそ、午後問題が毎回削りにくる急所です。

この記事で学べることは次のとおりです。

• 暗号利用モード（ECB・CBC・GCM）の違いと、AEADが機密性と完全性を同時に守る理由
• ハッシュ値の併記だけでは改ざんを検知できないケースと、その構造的な理由
• HMACとデジタル署名の違い（誰が偽造できるか・否認防止できるか）を記述で書き分ける方法
• 鍵管理の不備（同居保管・使い回し・ローテーションなし）をどう指摘すれば加点されるか
• 通信時の暗号化（TLS）と保管時の暗号化、エンドツーエンドの暗号化・署名の役割分担

暗号アルゴリズムそのものの仕組みをまだ固めたい方は、先に共通鍵暗号方式の基礎とハッシュ関数とMACの解説を読んでから戻ってくると、設問の狙いがはっきり見えます。

事例シナリオ：産業機械メーカーのファームウェア配布システム

まずは架空のH社を舞台にしたシナリオを読んでください。設問はこの事例の中から出します。実際の午後問題と同じように、「暗号を使っているのに、何が守れていないのか」を意識しながら読み進めてください。

なお、本記事に登場する企業名・ドメイン名・ファイル名はすべて架空値です。ドメインは example.jp と表記します。

登場するシステムと利用者

H社は産業機械を製造するメーカーで、出荷済みの制御装置に対して定期的にファームウェアの更新版を配布しています。配布には自社構築の「更新ファイル配布サーバ」（https://dist.example.jp）を用いており、関係者は次のとおりです。

• H社 開発部：ファームウェアをビルドし、配布サーバへアップロードする
• H社 情報システム部：配布サーバを運用し、暗号化と公開作業を担当する
• 協力会社の保守員（約200名）：顧客工場に出向き、配布サーバからダウンロードした更新ファイルを制御装置へ適用する

配布サーバはHTTPS（TLS 1.3）で公開されており、保守員はIDとパスワードでログインしてファイルをダウンロードします。

現行の暗号化と完全性チェックの実装

情報システム部は、次の対策を実施していました。

• 保管時の暗号化：配布サーバ上のファームウェアファイルは、AES-256のECBモードで暗号化して保存している
• 鍵の管理：暗号化に使う共通鍵は、配布サーバ内のアプリケーション設定ファイルに平文で記載されている。鍵は5年前のシステム構築時から一度も変更されておらず、社内の別システムのバックアップ暗号化にも同じ鍵を使い回している
• 完全性の確認：保守員が改ざんの有無を確認できるよう、各ファームウェアのSHA-256ハッシュ値を、ファイルをダウンロードする同じWebページ上に併記している
• 通信の保護：配布サーバとの通信はTLSで暗号化されている

保守員向けの手順書には「ダウンロード後、Webページに掲載されたハッシュ値と、手元で計算したハッシュ値が一致することを確認してから適用すること」と記載されていました。

発生したインシデント

ある日、H社は顧客工場から「更新後の制御装置が想定外の通信を外部へ行っている」との連絡を受けます。調査の結果、次の事実が判明しました。

攻撃者は、情報システム部の運用担当者の認証情報を窃取して配布サーバに侵入していました。侵入後、攻撃者は設定ファイルに平文で記載されていた共通鍵をそのまま入手し、正規のファームウェアを復号したうえで、不正な通信機能を追加した改造版を同じ鍵で暗号化し、元のファイルと置き換えました。

さらに攻撃者は、改造版ファームウェアのSHA-256ハッシュ値を自分で計算し、ダウンロードページに掲載されているハッシュ値も同時に書き換えました。保守員は手順書どおりハッシュ値を照合しましたが、掲載値と計算値は当然一致します。改ざんは検知されないまま、複数の顧客工場の制御装置へ不正なファームウェアが適用されました。

設問

事例を踏まえて、次の設問に記述で答えてください。実際の午後問題と同じように、字数と要点の絞り込みを意識してください。

設問1

保守員はダウンロードページに掲載されたハッシュ値と、手元で計算したハッシュ値を照合していたにもかかわらず、ファームウェアの改ざんを検知できませんでした。その理由を60字以内で述べてください。

設問2

配布サーバでは、ファームウェアの暗号化にAES-256のECBモードを使用していました。ECBモードを用いることの問題点を2つ挙げ、あわせて、機密性と完全性を同時に確保するためにどの暗号利用モードへ変更すべきかを、その理由とともに述べてください。

設問3

(1) H社の鍵管理には複数の不備があります。事例から読み取れる不備を挙げ、それぞれに対する改善策を述べてください。

(2) 改ざんを根本的に検知できるようにするため、H社はファームウェアにデジタル署名を付与する方式を採用することにしました。HMACではなくデジタル署名が適している理由を、200名の保守員へ配布するという条件を踏まえて80字以内で述べてください。

(3) 配布サーバとの通信はTLSで暗号化されているにもかかわらず、ファームウェアそのものを暗号化・署名する必要がある理由を述べてください。

回答例

記述式の模範解答は、事実を漏らさず、かつ冗長にしないのがコツです。以下は要点を押さえた解答例です。

設問1の回答例

（60字以内）ハッシュ値はファイルと同じサーバの同じページに置かれており、攻撃者がファイルとハッシュ値の両方を書き換えられたため。

ハッシュ関数には鍵が使われていないため、そのファイルを持つ者なら誰でも正しいハッシュ値を再計算できます。したがって、ハッシュ値が改ざん者の手が届く場所に置かれている限り、それは改ざん検知の役に立ちません。ハッシュ値が有効なのは、値が改ざんされない別経路（信頼できる第三者のサイト、書面、あらかじめ配布された値など）で伝えられる場合に限られます。

設問2の回答例

ECBモードの問題点（2つ）：

1. 同じ平文ブロックが常に同じ暗号文ブロックに変換されるため、平文中の繰り返しパターンが暗号文にそのまま現れ、内容が推測される。すなわち機密性が不十分である
2. ブロックごとに独立して暗号化されるため、攻撃者が暗号文のブロックを入れ替え・複製・削除しても検知できない。すなわち完全性がまったく保証されない

変更すべきモード：AES-GCMなどの認証付き暗号（AEAD）へ変更する。AEADは暗号化と同時に認証タグを生成し、復号時にタグを検証することで、機密性と完全性・真正性を一つの処理でまとめて確保できる。タグが一致しない場合は復号結果を破棄するため、改ざんされた暗号文をそのまま受け入れることがない。なお、GCMでは同じ鍵に対してIV（nonce）を再利用すると安全性が崩れるため、暗号化のたびに一意なIVを生成する運用が前提となる。

設問3(1)の回答例

不備1：暗号鍵を暗号化対象と同じサーバ上に、しかも平文で保管している。 改善策：鍵はKMS（鍵管理システム）やHSM（耐タンパ性を持つハードウェア）で暗号化対象と分離して保管し、アクセス権を最小限の権限者に限定する。アプリケーションからは都度APIで取得し、設定ファイルに平文で書かない。

不備2：同じ鍵を別システムのバックアップ暗号化にも使い回している。 改善策：用途・システムごとに鍵を分離する。1つの鍵が漏えいしたときの影響範囲を、その鍵で守っている範囲内に限定する。

不備3：5年間一度も鍵を変更していない（ローテーションがない）。 改善策：鍵の有効期限を定めて定期的に更新し、危殆化が疑われる場合は直ちに鍵を失効・再発行する手順をあらかじめ定めておく。

設問3(2)の回答例

（80字以内）HMACは検証側も同じ鍵を持つため、200名の保守員の誰か1名から鍵が漏えいすれば正しいMACを偽造でき、送信者を特定する否認防止もできないから。

補足すると、デジタル署名はH社だけが持つ秘密鍵で生成し、保守員は公開鍵で検証します。公開鍵は漏えいしても署名を偽造できないため、多数の検証者へ安全に配布できます。加えて、署名を作れるのは秘密鍵の保有者だけなので、真正性（H社が作ったファームウェアであること）と否認防止が同時に成立します。

設問3(3)の回答例

TLSが保護するのは通信経路上のデータだけであり、サーバに到達した時点で復号され、配布サーバ上には平文（またはサーバが復号できる状態）で存在する。本事例のようにサーバ自体が侵害された場合、TLSは何の防御にもならない。したがって、保管時のデータそのものを暗号化して機密性を守り、さらにファームウェアに署名を付与して、配布元から適用先の制御装置に届くまでの改ざんを検知できるようにする必要がある。署名の検証を制御装置側で行えば、経路上のどこで改ざんされても適用前に弾ける。

採点ポイント

ここが本シリーズの肝です。同じ内容を書いても、要点に触れているかどうかで部分点が大きく変わります。

加点される要点

• 設問1：「ハッシュ値がファイルと同じ場所（同じ管理下）にある」「攻撃者が両方を書き換えられる」の2点を必ず書くこと。「ハッシュ値では改ざんを検知できない」とだけ書くと、ハッシュ関数そのものが無力だという誤った理解と受け取られ、加点されません。無力なのはハッシュ関数ではなくハッシュ値の置き場所です。
• 設問2：ECBの問題点は「同じ平文が同じ暗号文になる（機密性）」と「ブロック単位の改変を検知できない（完全性）」の2つの性質に分けて書くこと。片方だけだと設問の「2つ挙げよ」を満たしません。AEADは「暗号化と認証タグ生成を同時に行う」という機構まで触れると強い解答になります。
• 設問3(1)：「鍵と暗号化対象を分離する」というキーワードが軸です。加えて「使い回しの禁止」「ローテーション」に触れると満点圏です。
• 設問3(2)：「検証者も鍵を持つため偽造できる」という一点が最大の分岐点です。ここを書けているかどうかで、HMACと署名の理解が本物かが判定されます。
• 設問3(3)：「TLSは経路のみ」「サーバ上では平文」という因果を書くこと。

よくある減点・失点パターン

第一の失点は、設問1で「SHA-256は危殆化しているから」と書いてしまうことです。事例のどこにも衝突攻撃の話は出ておらず、問題はアルゴリズムの強度ではなくハッシュ値を守る仕組みがないことにあります。事例に書かれていない前提を持ち込むのは午後で最も損な失点です。

第二の失点は、設問2で「CBCモードに変更する」と答えてしまうことです。CBCはECBのパターン露出の問題こそ解消しますが、それ自体は完全性を保証しません。設問が「機密性と完全性を同時に確保する」と指定している以上、答えはAEAD（GCM等）です。CBCを選ぶなら、別途HMACを併用する構成まで書かなければ設問の条件を満たしません。

第三の失点は、設問3(2)で「デジタル署名のほうが安全だから」という抽象的な理由で終わることです。安全という語は採点者に何も伝えません。「誰が鍵を持つか」「誰が偽造できるか」「否認防止が成立するか」という具体的な差分に落として書いてください。

第四の失点は、鍵管理の設問で対策を「鍵を厳重に管理する」で済ませてしまうことです。厳重の中身、すなわち「保管場所の分離」「アクセス権の限定」「用途ごとの分離」「定期更新と失効手順」のどれかに具体化して初めて点になります。

字数調整のコツ

暗号の設問は要素が多く、字数超過が起こりがちです。削るときはアルゴリズム名を先に削るのがコツです。「AES-256のECBモードで暗号化されたファームウェアの」といった修飾は、「暗号化されたファイルの」で足ります。逆に絶対に削ってはいけないのは、誰が何の鍵を持つかと何が守れて何が守れないかの骨格です。60字以内なら「主体＋操作＋結果」の1文、80字以内なら「理由＋帰結」の2要素、と型を決めておくと現場で迷いません。

頻出パターン

このテーマはSC午後で繰り返し問われます。本番で素早く見抜くための「型」を整理します。

ハッシュ値の置き場所を問う型

事例に「ハッシュ値を掲載している」「チェックサムを併記している」と書かれていたら、まずそのハッシュ値は誰が書き換えられるのかを確認してください。ファイルと同じサーバ、同じページ、同じ管理者権限の下にあるなら、その完全性チェックは形式だけのものです。判定基準はシンプルで、次のとおりです。

• ハッシュ値のみ：偶発的な破損・転送エラーは検知できるが、意図的な改ざんは検知できない（鍵がないため誰でも再計算できる）
• HMAC：共通鍵を知らない者は正しい値を作れないため、改ざんを検知できる。ただし検証者も同じ鍵を持つ
• デジタル署名：秘密鍵の保有者しか生成できないため、改ざん検知に加えて真正性と否認防止まで成立する

この3段階の違いはハッシュ関数とMACの基礎記事とデジタル署名とPKIの基礎記事で図解しています。午後では「どれを使うべきか」と「なぜ下位では不十分か」がセットで問われるので、両方を言語化できる状態にしておいてください。

暗号利用モードを問う型

暗号利用モードは、次の対応で覚えると設問に即答できます。

• ECB：同じ平文ブロックが同じ暗号文になる。パターンが露出し、ブロックの並べ替えも検知できない。実務でも試験でも「使ってはいけない例」として登場する
• CBC：直前の暗号文ブロックと連鎖させるためパターンは消えるが、完全性は別途MACが必要。パディングオラクル攻撃の題材にもなる
• CTR：ストリーム暗号のように扱えるが、これも単体では完全性を守らない
• GCM・CCM（AEAD）：暗号化と認証タグ生成を同時に行い、機密性と完全性・真正性をまとめて確保する

「機密性だけか、完全性まで含むか」で仕分けるのが最短ルートです。事例に「暗号化しているので改ざんもされない」といった記述が出てきたら、それは高確率で誤りを指摘させる設問の伏線です。

鍵管理を問う型

鍵管理の設問は、着眼点が毎回ほぼ同じです。事例を読みながら次の5点をチェックすると、指摘漏れがなくなります。

• 保管場所：鍵が暗号化対象と同じ場所（同じサーバ、同じDB、同じリポジトリ）に置かれていないか
• 保管形式：平文でファイルやソースコードに書かれていないか。KMS・HSMを使っているか
• アクセス権：鍵にアクセスできる人が必要最小限か。運用担当者全員が触れる状態になっていないか
• 使い回し：複数のシステム・用途・相手先で同じ鍵を共用していないか
• ライフサイクル：有効期限とローテーション、危殆化時の失効・再発行手順が定義されているか

鍵の危殆化への対応は鍵管理と危殆化の解説記事でも整理しています。午後では「鍵が漏れた前提で何が起きるか」を問う設問も多く、その場合はその鍵で守っていた全データの機密性が失われるという影響範囲まで書くと加点されます。

暗号化の適用範囲を問う型

近年は「TLSを使っているのになぜ守れなかったのか」という一歩踏み込んだ問い方が増えています。適用範囲は次の3層で整理してください。

• 通信時の暗号化（TLS）：経路上の盗聴・改ざんを防ぐ。終端したサーバ上では平文になる
• 保管時の暗号化：ストレージやバックアップの持ち出し、DB流出に効く。ただし鍵をそのサーバが持っていれば、サーバ侵害時には無力
• エンドツーエンドの暗号化・署名：データの生成元で暗号化・署名し、最終的な受信者が復号し、署名を検証する（復号できるのは受信者だけだが、署名の検証は公開鍵を持つ誰もが行える）。経路上の中継サーバが侵害されても守れる

配布物を特定の相手にだけ読める形で届ける場面では、ハイブリッド暗号（データ本体を共通鍵で暗号化し、その共通鍵を受信者の公開鍵で暗号化して渡す方式）が定番の解になります。ただしハイブリッド暗号が担うのは機密性であり、完全性・真正性はデジタル署名（またはAEADの認証タグ）で別に担保する必要があります。仕組みはハイブリッド暗号方式の解説記事で確認しておくと、記述の引き出しが増えます。

この事例が実務と直結する理由

私がCIOだった頃に情報の格付けとアクセス権設計に膨大な時間を費やした経験から言えば、暗号化そのものよりも「誰が鍵に触れられるか」を設計するほうがはるかに難しいのが現実です。本事例で攻撃者が最初に手にしたのも脆弱な暗号アルゴリズムではなく、設定ファイルに平文で置かれた鍵でした。ソフトウェア更新の配布経路を狙う攻撃は現実のサプライチェーン攻撃そのものであり、更新ファイルへの署名検証は、いまや制御機器やIoT機器の設計要件になっています。試験の事例は机上の空論ではなく、現場でそのまま起こりうる失敗を凝縮したものです。

まとめ：暗号は「何を守れないか」から読む

令和7年秋 午後 問2のテーマである暗号技術による機密性・完全性の担保は、暗号を導入済みの組織ほど陥りやすい落とし穴を突く良問領域です。押さえるべき骨格は3点です。ハッシュ値は置き場所を守れなければ改ざん検知にならないこと、暗号利用モードは機密性だけを守るものと完全性まで守るAEADを区別すること、そして鍵は暗号化対象と分離し、使い回さず、更新することです。

事例を読むときは、「何を暗号化しているか」ではなく「この暗号化では何が守れないか」から入ってください。TLSは経路しか守らない、保管時暗号化は鍵が同居していれば守れない、ハッシュは鍵がないから守れない。この引き算の視点を持てば、設問が指し示す穴は読んでいる途中で自然に浮かび上がります。それがそのまま午後（科目B）の得点力になります。

本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。

参考資料

• IPA 情報処理安全確保支援士試験 過去問題（令和7年度秋期）：https://www.ipa.go.jp/shiken/mondai-kaiotu/2025r07.html
  • 本記事は令和7年度 秋期 午後 問2をテーマにした事例解説です。IPAの解答例（出題趣旨）によると、問2は「暗号資産交換業における暗号鍵の管理」を題材に、暗号の適切な利用による機密性・完全性の担保を問う出題でした。詳細な設問・解答例は上記の公式PDFを参照してください。本文中の事例は著作権に配慮し、テーマに沿って独自に作成した架空シナリオです。
• IPA 暗号技術（CRYPTREC暗号リストの策定・運営）：https://www.ipa.go.jp/security/crypto/index.html
• NIST SP 800-38D（AES-GCM の仕様と利用上の注意）：https://csrc.nist.gov/pubs/sp/800/38/d/final