基本情報技術者 2010年秋期午前（科目A）問39

問題文

ディジタル署名に用いる鍵の種別に関する組合せのうち、適切なものはどれか。

選択肢

ア：

イ：

ウ：

エ：（正解）

ディジタル署名に用いる鍵の種別に関する組合せ【午前2 解説】

要点まとめ

結論：ディジタル署名は作成に「秘密鍵」、検証に「公開鍵」を用いるのが正しい。非否認性と検証公開性を両立するためである。
根拠：署名は署名者のみが保持する秘密鍵でメッセージダイジェストを変換し、誰でも対応する公開鍵で真偽を検証できる仕組みだからである。
差がつくポイント：暗号化と署名の鍵の役割を混同しないこと。暗号化は受信者の公開鍵／秘密鍵ペア、署名は作成者の秘密鍵／公開鍵ペアを使う。

正解の理由

正解はエ（作成に秘密鍵、検証に公開鍵）です。
ディジタル署名の基本手順は「メッセージをハッシュ化してダイジェストを作る → 署名者の秘密鍵でそのダイジェストを署名（暗号化）する」という流れです。検証側は署名と原文からダイジェストを再計算し、署名を署名者の公開鍵で復号して一致するか確認します。これにより、署名がその秘密鍵を持つ者によって作成されたこと（真正性・非改ざん・非否認）が保証されます。したがって「作成：秘密鍵」「検証：公開鍵」の組合せが正しい理由です。

正解: エ

よくある誤解

「署名は公開鍵で作る」と思い込みやすい：公開鍵は検証用で、署名の作成には使えません。
共通鍵（対称鍵）でも署名できると考える誤り：共通鍵は双方が共有するため非否認性が成立せず、署名の要件を満たしません。
暗号化と署名の鍵の役割を混同する：暗号化（機密性）は受信者の公開鍵を使う場合があるが、署名は送信者の秘密鍵を使います。

解法ステップ

選択肢の表を見て「作成に使う鍵」と「検証に使う鍵」を明確に区別する。
「署名の作成＝その人がしか使えない鍵（秘密鍵）」と置き換える。
「検証＝だれでも検査できる鍵（公開鍵）」と置き換える。
選択肢を照合して、作成が秘密鍵で検証が公開鍵になっているものを選ぶ（エ）。

選択肢別の誤答解説

ア（共通鍵｜秘密鍵）：共通鍵は双方で共有するため非否認性が担保されず、検証に相手の秘密鍵を使う意味もない。誤り。
イ（公開鍵｜秘密鍵）：作成に公開鍵を使うという逆転が起きている。公開鍵は誰でも持てるため署名の作成には使えない。誤り。
ウ（秘密鍵｜共通鍵）：検証に共通鍵を使う設計は不適切。共通鍵は検証者が独自に持たないと成り立たないため現実的でなく非否認性が失われる。誤り。
エ（秘密鍵｜公開鍵）：作成を秘密鍵、検証を公開鍵で行う正しい組合せであり、これが正解。

補足コラム

代表的なディジタル署名アルゴリズムには RSA、DSA、ECDSA などがあります。一般的な流れはメッセージ M に対してハッシュ関数 H を使い

h = H (M)

を作成し、署名

S = Sign_{s k} (h)

（署名者の秘密鍵で処理）を行い、検証は

h^{'} = H (M)

と公開鍵で

S

を検証して一致を確認します。署名は「真正性・完全性・非否認性」を提供しますが、機密性は保証しない点に注意してください。

簡単な擬似式：

S = Sign_{秘密鍵} (H (M))

検証：

Verify_{公開鍵} (M, S)

コード例（概念説明用、ライブラリ依存）:

# 概念例（実用ではライブラリを使用してください）
h = hash_function(message)
signature = private_key.sign(h)
# 受信側
h2 = hash_function(message)
ok = public_key.verify(signature, h2)

FAQ

Q1: 共通鍵で署名はできないのか？
A1: 対称鍵でもメッセージ認証コード（MAC）は作れますが、送信者単独の証明（非否認性）はできません。署名とMACは目的が異なります。

Q2: 署名と暗号化を同時に行えるか？
A2: はい。一般には署名で送信者の正当性を保証し、必要なら受信者の公開鍵で暗号化して機密性も確保します。順序や手法に注意が必要です。

Q3: 公開鍵が偽造されるとどうなる？
A3: 公開鍵の正当性は証明書（CA）や信頼のチェーンで確認します。公開鍵単体の検証では中間者攻撃に対処できません。

関連キーワード: ディジタル署名、公開鍵暗号、秘密鍵、公開鍵、非否認性、ハッシュ関数、RSA、DSA、ECDSA、PKI、メッセージ認証コード（MAC）、電子署名、鍵管理

← 前の問題へ次の問題へ →

\ せっかくなら /

基本情報技術者を
クイズ形式で学習しませんか？

クイズ画面へ遷移する→

すぐに利用可能！