午前I問題
ハッシュ関数の性質に関する記述のうち、最も適切なものはどれか。
ア）ハッシュ関数は入力データを鍵を用いて可逆的に変換する関数であり、ハッシュ値から元のデータを復元できる。
イ）暗号学的ハッシュ関数は、異なる入力から同一のハッシュ値が生成される衝突が理論上存在するが、それを意図的に見つけ出すことが計算量的に困難な性質（衝突耐性）を持つ。
ウ）入力データのうち1ビットだけを変更しても、出力されるハッシュ値はほとんどの場合元の値と数ビットしか変わらない。
エ）MD5やSHA-1は現在でも衝突攻撃に対する耐性が十分であり、コード署名や証明書の分野で推奨されるアルゴリズムである。
午前I の解答・解説を見る
正解： イ）
解説：
- ア）不正解。ハッシュ関数は不可逆な一方向性関数であり、鍵を用いた可逆変換ではない。ハッシュ値から元のデータを計算により復元することはできない（原像計算困難性）。
- イ）正解。ハッシュ関数の出力は有限のビット長であるのに対し入力は無限に存在しうるため、鳩の巣原理により衝突（異なる入力が同じハッシュ値になること）は理論上必ず存在する。暗号学的ハッシュ関数に求められるのは「衝突が存在しない」ことではなく、「衝突する入力の組を意図的に見つけることが計算量的に困難である」という衝突耐性である。
- ウ）不正解。暗号学的ハッシュ関数は雪崩効果（アバランシェ効果）を持ち、入力のわずか1ビットの変化でも出力のハッシュ値は大きく（統計的にはほぼ半分のビット）変化する設計になっている。
- エ）不正解。MD5とSHA-1はいずれも実用的な衝突攻撃が実証されており、現在ではコード署名や証明書用途では非推奨とされている。SHA-256以上のSHA-2系列やSHA-3系列の使用が推奨される。
午前II問題
ソフトウェアのコード署名（Code Signing）に関する記述のうち、最も適切なものはどれか。
ア）コード署名はソフトウェアの脆弱性の有無を検証するものであり、署名済みのソフトウェアには脆弱性が存在しないことが保証される。
イ）コード署名は開発者の秘密鍵でソフトウェアのハッシュ値に対してデジタル署名を行うものであり、利用者は対応する公開鍵で署名を検証することで、配布元の真正性とファイルが改ざんされていないことを確認できる。
ウ）コード署名用の秘密鍵は開発チーム全員が共有し、ビルドサーバのローカルディスクに平文で保存しておくことが一般的な運用である。
エ）タイムスタンプ署名を付与しなくても、コード署名の証明書が有効期限切れになった場合、過去に署名されたソフトウェアの署名は自動的に有効なままとなる。
午前II の解答・解説を見る
正解： イ）
解説：
- ア）不正解。コード署名が保証するのは「署名者の真正性」と「署名後にファイルが改ざんされていないこと」であり、ソースコード自体に脆弱性がないことを保証するものではない。脆弱性の有無はSAST・DAST等の別の手段で検証する必要がある。
- イ）正解。コード署名は対象ファイルのハッシュ値を計算し、それを署名者の秘密鍵で暗号化（署名）することで実現される。検証者は公開鍵でこの署名を復号しハッシュ値を取り出し、実際のファイルから計算したハッシュ値と比較することで、改ざんの有無となりすましでない配布元であることを確認できる。
- ウ）不正解。コード署名用の秘密鍵は組織にとって極めて重要な資産であり、漏洩するとマルウェアに正規の署名を付けて配布されるなど深刻な被害につながる。HSM（Hardware Security Module）等での厳格な保管・アクセス制御・監査ログの記録が推奨され、平文保存や無制限の共有は避けるべきである。
- エ）不正解。タイムスタンプ署名（Trusted Timestamp）を付与しておくと、証明書自体が後に失効・期限切れになっても「署名された時点では証明書が有効だった」ことを証明でき、署名の有効性を維持できる。タイムスタンプがない場合、証明書の有効期限切れ後は署名の検証結果が不確実になる。
午後問題
産業機器の制御ソフトウェアを開発するF社は、顧客に配布するファームウェア更新プログラムにコード署名を導入することになった。現状のリリースプロセスは次のとおりである。
- ビルドサーバでコンパイルされたバイナリファイルを、リリース担当者が手元のPCにダウンロードし、ローカルに保管している署名用秘密鍵（USBメモリに保存）を使って署名している
- 署名済みバイナリはWebサイトからダウンロード提供されているが、ダウンロードページにはSHA-256などのハッシュ値は掲載されていない
- 過去に一度、リリース担当者のPCがマルウェアに感染し、USBメモリ内の秘密鍵にアクセスされた可能性が指摘されたが、鍵のローテーションは行われなかった
設問1
利用者が入手したファームウェアが改ざんされていないこと、および正規のF社が配布したものであることを検証できるようにするために、F社のWebサイトで追加すべき情報と、その情報を利用者がどのように使うかを説明せよ。
設問1の解答・解説を見る
正解例： ダウンロードページに、配布するバイナリファイルのSHA-256ハッシュ値と、コード署名の検証に必要な公開鍵証明書（またはその指紋）を掲載する。利用者はダウンロードしたファイルから自身でハッシュ値を計算し、掲載値と一致するかを確認することで改ざんの有無を検証できる。また、OSやツールが提供する署名検証機能を用いて、ファイルに付与されたデジタル署名をF社の公開鍵証明書で検証することで、正規のF社が配布した真正なファイルであることを確認できる。
解説・採点基準（計15点）：
| 採点項目 | キーワード | 配点 |
|---|---|---|
| ハッシュ値の掲載と利用者による突合検証に言及 | SHA-256等のハッシュ公開・比較 | 5点 |
| 公開鍵証明書による署名検証の仕組みに言及 | 公開鍵・署名検証 | 6点 |
| ハッシュ値検証（改ざん検知）と署名検証（真正性確認）の役割の違いに言及 | 改ざん検知と真正性確認の区別 | 4点 |
設問2
署名用秘密鍵の管理体制について、現状のリスクを指摘し、改善すべき運用方法を2つ述べよ。
設問2の解答・解説を見る
正解例：
現状のリスク：署名用秘密鍵がリリース担当者個人のPC・USBメモリという管理が脆弱な環境に保管されており、PCのマルウェア感染により鍵が窃取された可能性がある。窃取された場合、攻撃者が正規の署名を付けたマルウェアを配布できてしまう重大なリスクとなる。また、感染が疑われた後も鍵のローテーションが行われていない点も問題である。
改善策（下記から2つ）：
- 署名用秘密鍵をHSM（Hardware Security Module）またはクラウドの鍵管理サービス（KMS）内に保管し、秘密鍵自体を外部に取り出せない形で署名処理のみをHSM/KMS内部で実行する運用に変更する。
- 鍵へのアクセスを最小権限の担当者に限定し、操作ログを記録・監査する。また、鍵の漏洩が疑われた時点で直ちに鍵をローテーション（失効・再発行）し、旧鍵で署名済みの正規リリースの真正性影響範囲を確認する手順を整備する。
解説・採点基準（計15点）：
| 採点項目 | キーワード | 配点 |
|---|---|---|
| 個人PC・USB保管のリスク（漏洩・マルウェア感染）を的確に指摘 | 秘密鍵漏洩リスク | 4点 |
| HSM/KMSなど専用の鍵管理基盤の利用に言及 | HSM・KMS | 5点 |
| アクセス制御・監査ログの整備に言及 | 最小権限・監査ログ | 3点 |
| 漏洩疑い時の鍵ローテーション・失効手順の整備に言及 | 鍵ローテーション・失効 | 3点 |
「鍵のローテーションを行わなかったこと自体が問題」という指摘があれば加点。HSM/KMSへの言及がなくとも、パスワード保護・アクセス制御の強化など代替の合理的な改善策があれば部分点を与える。
重要キーワード
| 用語 | 説明 |
|---|---|
| コード署名 | ソフトウェアのハッシュ値を開発者の秘密鍵で署名し、配布元の真正性と非改ざんを利用者が検証できるようにする仕組み |
| 衝突耐性 | 異なる入力から同一のハッシュ値を意図的に作り出すことが計算量的に困難であるという、暗号学的ハッシュ関数に求められる性質 |
| タイムスタンプ署名 | 署名が行われた時刻を第三者機関が証明する仕組み。証明書の有効期限切れ後も署名時点での有効性を証明できる |
| HSM | Hardware Security Module。暗号鍵の生成・保管・演算を専用のセキュアなハードウェア内で行い、鍵の外部流出を防ぐ装置 |
| 雪崩効果 | 入力データのわずかな変化が出力のハッシュ値を大きく変化させる、暗号学的ハッシュ関数に求められる性質 |
| 鍵ローテーション | 漏洩の有無にかかわらず定期的または即時に鍵を更新する運用。漏洩時の被害を時間的に限定する（鍵管理も参照） |
まとめ
- 午前I視点： ハッシュ関数は不可逆かつ衝突耐性を持つ一方向性関数であり、MD5・SHA-1は既に衝突攻撃が実証済みで非推奨という知識が基礎となる。
- 午前II視点： コード署名は「秘密鍵で署名・公開鍵で検証」という非対称暗号の応用であり、脆弱性の不在を保証するものではない点、タイムスタンプ署名の役割が頻出論点。
- 午後視点： 実務では署名鍵の安全な保管（HSM/KMS化）とアクセス制御、漏洩時の速やかなローテーション、利用者側でのハッシュ値・署名検証を可能にする情報公開の3点がコード署名運用の核心となる。