ITパスポート 2017年 秋期 問72
問題文
アプリケーションプログラムやデバイスドライバなどを安全に配布したり、それらが不正に改ざんされていないことを確認したりするために利用するものはどれか。
選択肢
ア:SMTP
イ:WPA2
ウ:コード署名(正解)
エ:電子透かし
🔒 解説は解答すると表示されます
アプリケーション配布や改ざん確認に使うものはどれか【ITパスポート 解説】
正解の理由
アプリケーションやデバイスドライバを「安全に配布」し、「改ざんされていないことを確認」する目的には、配布元の真正性(誰が作ったか)と内容の完全性(配布物が途中で変えられていないか)を両方確認できる仕組みが必要です。これを満たすのがコード署名(コードしょめい、code signing:ソフトウェアにデジタル署名を付ける技術)です。署名は開発者が自分の秘密鍵で配布ファイルのハッシュに署名を付け、受け手は公開鍵(と証明書)でその署名を検証します。検証が通れば「配布元が確かで、配布後に改ざんされていない」ことが保証されます。したがって、選択肢の中では ウ が正解です。
(用語補足)
- コード署名:ソフトウェアに「作成者と改ざんがないこと」を示すデジタル署名を付ける技術
- 証明書:公開鍵と発行者情報を結びつけるデジタル文書。信頼のチェーンを作るために使われる
解法ステップ
- 問題文のキーワードを探す:「安全に配布」「不正に改ざんされていないことを確認」→ これは「真正性(誰が作ったか)」と「完全性(内容が改変されていないか)」の両方を確認する話題。
- 各選択肢が何を提供するかを整理する
- SMTP:メール送信のプロトコル(通信手段) → 配布や改ざん検出には直接関係しない
- WPA2:Wi‑Fiの無線通信保護 → ネットワークの通信路の保護であって、配布後の改ざん検出ではない
- コード署名:配布物に署名を付け、改ざん検出と配布元の確認ができる → 条件に合致
- 電子透かし:ファイルに目には見えない識別情報を埋め込む技術 → 著作権管理や追跡向けで、実行ファイルの改ざん検出には向かない
- 条件に最も合致するものを選ぶ → コード署名(ウ)
選択肢別の誤答解説
-
ア: SMTP
SMTP(Simple Mail Transfer Protocol:メールを送るための仕組み)はメール配送のプロトコルです。メールの送受信や配信経路に関する技術であり、ソフトウェアの配布物自体の改ざん検知や配布元の保証を行う機能はありません。したがって不正解です。 -
イ: WPA2
WPA2(Wi‑Fi Protected Access 2:無線LANの暗号方式)は無線通信の暗号化と認証を提供します。ネットワーク上の通信を守る技術で、ソフトウェアファイルに署名を付けて改ざんを検出するものではありません。配布経路(通信路)を保護する点は関係しますが、配布後のファイル改ざんの検知や配布元の証明には使えないため不正解です。 -
ウ: コード署名
コード署名は配布ファイルにデジタル署名を付けます。受け手側は署名を検証して「この配布元が署名したものか」「配布後に内容が変えられていないか」を確認できます。したがって設問の要件に合致します。これは正解です。 -
エ: 電子透かし
電子透かし(デジタルウォーターマーク)は画像・音声・文書などに埋め込む識別情報で、所有者の特定や不正コピーの追跡に使われます。しかし実行ファイルやドライバの「改ざんがないことを証明する」用途には一般的ではありません。透かしは改変の痕跡を示せる場合もありますが、コード署名のように「公開鍵で検証できる改ざん検知」と「配布元の証明」を一体で提供するわけではないため不適切です。
よくある誤解
-
「署名=暗号化」と混同する
- 誤解:署名するとファイルが暗号化されて中身が隠れると思う。
- 正しくは:コード署名はファイルを暗号化しません。署名は「ハッシュ値に対する作成者の署名」で、改ざんの検出と作成者の証明が目的です。暗号化は別に行う技術です。
-
「WPA2 や SMTP が改ざん検知に使える」と考える
- 誤解:通信を守る技術だから配布物も安全になるはずだ。
- 正しくは:通信経路を暗号化して安全に送ることはできますが、配布後に受け取ったファイルが改ざんされていないかを確認するには、受け手側で検証可能な署名などの仕組みが必要です。
-
「電子透かしでコードの安全性を保証できる」と思う
- 誤解:透かしがあれば改ざんがすぐ分かる。
- 正しくは:透かしは追跡や識別には有効でも、公開鍵で検証して即座に改ざんの有無を判定するコード署名とは用途が異なります。
補足コラム:コード署名は内部でどう動くか(簡単に)
- 開発者は配布ファイルのハッシュ(データを短い固定長にまとめた値)を作る。
- 開発者は自分の秘密鍵でそのハッシュに署名する。
- 数式的には(簡略化して)
- 配布パッケージには元データと署名、そして多くの場合は署名を確認するための証明書が添付される。
- 受け手側は証明書から公開鍵を取得し、署名を検証する。検証は署名がハッシュに対応しているかを見る。成功すれば「改ざんなし+発行者確認済み」となる。
- 実際の運用では CA(Certificate Authority:証明書を発行する信頼機関)により証明書の信頼性が支えられます。たとえば Microsoft の Authenticode、Apple の Developer ID、Android の APK signing などが実用例です。
FAQ
Q1: コード署名があればマルウェアでも安全なのですか?
A1: いいえ。署名は「誰が署名したか」を示します。悪意ある開発者が自分で署名したマルウェアは署名付きで配布され得ます。重要なのは「信頼できる発行元の証明書かどうか」を確認することです。
A1: いいえ。署名は「誰が署名したか」を示します。悪意ある開発者が自分で署名したマルウェアは署名付きで配布され得ます。重要なのは「信頼できる発行元の証明書かどうか」を確認することです。
Q2: 署名が期限切れやリボーク(失効)されたらどうなる?
A2: 証明書の有効期限や失効リスト(CRL)/オンライン証明書状態プロトコル(OCSP)で検証されます。期限切れや失効していれば、OSや実行環境が警告を出します。
A2: 証明書の有効期限や失効リスト(CRL)/オンライン証明書状態プロトコル(OCSP)で検証されます。期限切れや失効していれば、OSや実行環境が警告を出します。
Q3: ハッシュだけ(署名なし)ではダメですか?
A3: ハッシュ(チェックサム)だけでは改ざんを検出できますが、ハッシュ自体が改ざんされる恐れがあります。信頼できる第三者による署名があれば「ハッシュも正しい」という保証になります。従って、単独のハッシュは配布元の真正性を保証しません。
A3: ハッシュ(チェックサム)だけでは改ざんを検出できますが、ハッシュ自体が改ざんされる恐れがあります。信頼できる第三者による署名があれば「ハッシュも正しい」という保証になります。従って、単独のハッシュは配布元の真正性を保証しません。
Q4: 署名の検証はどうやって行うの?
A4: 多くのOSやランタイムが自動で署名を検証します。開発者や運用担当者は openssl や各プラットフォームのツールで手動検証もできます。
A4: 多くのOSやランタイムが自動で署名を検証します。開発者や運用担当者は openssl や各プラットフォームのツールで手動検証もできます。
関連キーワード: コード署名、デジタル署名、公開鍵暗号、ハッシュ値、証明書、Authenticode、APK署名、改ざん検知、配布の信頼性、秘密鍵管理

\ せっかくなら /
ITパスポートを
クイズ形式で学習しませんか?
クイズ画面へ遷移する→
すぐに利用可能!

