変更要約: 初版
2.2ハッシュとデジタル署名
一方向性・衝突耐性を持つハッシュ関数（SHA-256等）、共有鍵とハッシュ関数でメッセージの改ざんを検知するMAC/HMAC、公開鍵暗号を使って真正性と否認防止まで担保するデジタル署名、そしてタイムスタンプ・コードサイニング・XMLデジタル署名を学びます。
システムの完全性・真正性を守る技術を選ぶとき、実務家がまず自問すべきは「何を担保したいのか」です。単に「送信中に改ざんされていないか」を確認したいだけなのか、それとも「誰が作成したかを第三者に対しても証明し、後から本人が『自分ではない』と否認できないようにしたい」のかによって、選ぶべき技術はMAC/HMACかデジタル署名かに分かれます。この節ではハッシュ関数の性質を土台に、その使い分けの判断軸を学びます。
2.2.1ハッシュ関数（一方向性・衝突耐性・SHA-256）
- ハッシュ関数＝任意長のデータから固定長のハッシュ値（メッセージダイジェスト）を生成する関数。一方向性（ハッシュ値から元データを逆算できない）と衝突耐性（異なる2つの入力が同じハッシュ値になることが実質起こらない）の2性質が安全性の根幹。
- SHA-256＝256ビットのハッシュ値を出力する現行の推奨ハッシュ関数（SHA-2ファミリ）。旧世代のMD5・SHA-1は衝突が実際に発見されており、新規システムでの利用は避けるべき危殆化した方式である。
2.2.2MAC/HMAC（メッセージ認証符号）
- MAC（メッセージ認証符号）＝送受信者間で事前共有した共有鍵とメッセージから算出する検査符号。受信側で同じ鍵を使って再計算し一致すれば、通信経路上での改ざんがないこと（完全性）と、共有鍵を持つ相手からの送信であること（限定的な真正性）を確認できる。
- HMAC＝ハッシュ関数（SHA-256等）を用いてMACを構成する標準的な方式。MACは共有鍵を持つ全員が同じ計算ができてしまうため、「第三者に対して送信者が誰かを証明する」否認防止（第三者への証明）はできない点がデジタル署名との決定的な違い。
「MAC/HMAC＝共有鍵方式なので完全性と限定的な真正性のみ、否認防止は不可」「デジタル署名＝公開鍵暗号方式なので完全性＋真正性＋否認防止まで担保」の対比が最頻出です。「第三者に対する証明が必要か」がMAC/HMACとデジタル署名を分ける決定的な判断軸です。
2.2.3デジタル署名・タイムスタンプ・コードサイニング・XMLデジタル署名
- デジタル署名＝送信者がメッセージのハッシュ値を自身の秘密鍵で暗号化（署名）し、受信者が送信者の公開鍵で検証する方式。秘密鍵を持つのは本人のみのため、完全性・真正性に加え「本人しか署名できない＝後から否認できない」否認防止まで担保できる。
- タイムスタンプ＝ある時刻にそのデータが確かに存在していたことを第三者機関（時刻認証局）が証明する仕組み。デジタル署名と組み合わせることで「いつ署名されたか」まで証明でき、契約書等での長期的な証拠能力を高める。
- コードサイニング＝ソフトウェアの配布元が実行ファイルにデジタル署名を付与し、利用者が「改ざんされていないこと」と「正当な配布元であること」を検証できるようにする仕組み。XMLデジタル署名はXML文書の一部または全体に対してデジタル署名を適用する標準規格で、Webサービス（SOAP等）のメッセージ保護に使われる。
ある金融機関の情報セキュリティ担当者が、2つの異なる要件に対応する必要があるとします。要件Aは「拠点間の内部API通信で、伝送中の改ざんがないことを高速に確認したいが、通信は閉域網内で行われ第三者への証明までは不要」というものです。要件Bは「顧客が電子契約書に同意した事実を、後日その顧客が『同意していない』と主張しても第三者（裁判所等）に対して反証できる形で残したい」というものです。要件Aは「完全性の確認さえできればよく、否認防止までは不要」なので、より軽量なHMAC（共有鍵＋ハッシュ関数）を選ぶのが合理的です——閉域網内の拠点間なら鍵の事前共有も現実的で、公開鍵暗号を使うデジタル署名ほどの演算コストは不要です。一方、要件Bは「本人が後から否認できないことを、第三者に対しても証明したい」という否認防止そのものが目的であるため、デジタル署名（顧客本人の秘密鍵による署名）が必須です。さらに「いつ同意したか」まで法的な証拠として残したい場合は、タイムスタンプを署名に付加し、署名時刻を第三者機関（時刻認証局）に証明してもらうことで、電子契約書の長期的な証拠能力を高められます。もし要件Aのケースで誤ってMAC/HMACのみで「相手が本当にその拠点であることを社外の監査人にも証明したい」という要件が後から追加された場合、共有鍵を持つ全員が同じ計算をできてしまうMACでは第三者への証明ができないため、デジタル署名への切り替えが必要になります。このように、担当者は常に「完全性だけで足りるのか、真正性・否認防止まで第三者に証明する必要があるのか」を業務要件から見極め、MAC/HMACとデジタル署名を使い分けます。
| 観点 | MAC/HMAC | デジタル署名 |
|---|---|---|
| 使う鍵 | 共有鍵（送受信者で共通） | 署名者の秘密鍵＋検証者は公開鍵 |
| 担保できる性質 | 完全性＋限定的な真正性 | 完全性＋真正性＋否認防止 |
| 第三者への証明 | 不可（共有鍵を持つ誰でも計算可能） | 可能（秘密鍵は本人のみ保持） |
ひっかけ： 「HMACはハッシュ関数を使うのでデジタル署名と同様に否認防止まで担保できる」は誤りです——HMACは共有鍵を持つ全員が同じ計算をできてしまうため、「本人しか作成できない」という否認防止の前提が成り立ちません。否認防止が必要なら公開鍵暗号に基づくデジタル署名を使う必要があります。また「ハッシュ関数は一方向性さえあれば十分」も誤り＝衝突耐性（異なる入力から同じハッシュ値が実質生成できないこと）も同時に必要で、MD5・SHA-1のように衝突が発見された方式は署名やMACの基盤として使うべきではありません。
2.2.4この節のまとめ
- ハッシュ関数の安全性は一方向性と衝突耐性の両方が必要。MD5・SHA-1は衝突発見済みでSHA-256等を使う
- MAC/HMAC＝共有鍵方式で完全性＋限定的な真正性のみ（否認防止は不可）
- デジタル署名＝公開鍵暗号で完全性＋真正性＋否認防止まで担保。タイムスタンプ併用で「いつ」も証明できる
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 拠点間の内部API通信で、伝送中の改ざんがないことだけを高速に確認したい。通信は閉域網内で行われ、第三者に対して送信者を証明する必要はない。最も適した方式はどれか。
Q2. 顧客が電子契約書に同意した事実を、後日その顧客が「同意していない」と主張しても第三者（裁判所等）に対して反証できる形で残したい。この要件を満たす最も適切な技術の組み合わせはどれか。
Q3. あるソフトウェア配布元が、利用者に対して「配布された実行ファイルが改ざんされておらず、正当な配布元からのものであること」を検証可能にしたい。最も適した技術はどれか。