この記事でわかること

ハッシュ、MAC、デジタル署名の違い
「どこまで届くか」で見ると、3つの方式がすっきり分かること
デジタル署名だけでは認証が成立しない理由と、PKIの役割

3行まとめ

ハッシュは、改ざん検知だけ

MACは、改ざん検知と認証まで

デジタル署名は、改ざん検知と認証と否認防止まで

やりたいことは、まずこの3つ

改ざん検知：送ったものが、途中で書き換えられていないこと
認証：送った人が、本当にその人であること
否認防止：後から「送っていない」と言わせないこと

方式	改ざん検知	認証	否認防止
ハッシュ	○	×	×
MAC	○	○	×
デジタル署名	○	○	○

ハッシュ：改ざん検知だけ

できること

対象データを固定長の文字列に変換する
同じデータからは、同じハッシュ値が生成される
相手からもらったハッシュ値と、こちらで計算したハッシュ値が同じなら、改ざんされていないと判断できる

できないこと

誰が作ったかの証明
後から「作っていない」と言わせないこと

なぜ届かないのか

ハッシュ値とデータを渡す人が攻撃者であることは、否定できません。

攻撃者がデータとハッシュの両方を作り直せば、受け取る側は気づけません。

実務例

ダウンロードファイルのチェックサム
ファイルとチェックサムの両方を、信頼できない場所から取ってきたら、そのチェックサム自体が信用できない

MAC：改ざん検知と認証まで

できること

改ざん検知
認証

共通の秘密鍵を使うことで、ハッシュの変換方式を二人だけのものにします。

二人だけでしか使われない変換であることがわかるため、「共通鍵を知っている相手が作った」と判断できます。

できないこと

否認防止

二人とも変換が可能だからです。

どちらが作ったかは、証明できていません。

実務例

WebhookのHMAC検証
サービス側と受け取る側で秘密鍵を共有し、通知が本当にそのサービスから来たものかを確認する
相手が特定の1社で、後から第三者に証明する必要がない場面では、MACで十分

MACでは足りない場面

後から第三者に「この人が送った」と証明したい場面

デジタル署名：3つ全部

できること

改ざん検知
認証
否認防止

仕組み

秘密鍵で署名する
公開鍵で検証する

検証方法は二人で共有できますが、変換方法は共有されていません。

署名を作れるのは、秘密鍵の持ち主だけです。

否認防止が成り立つ条件

秘密鍵が適切に管理されている前提で、秘密鍵の持ち主だけが作れる以上、後から「作っていない」と言っても、署名がそれを否定する根拠になります。

実務例

JWTのRS256
TLSのサーバ証明書
コード署名

検証する側はたくさんいても、作る側は1人（または1組織）でなければならない場面で使います。

署名だけでは、認証は成立しない

ここが、勉強していて一番引っかかったところです。

署名の検証でわかること

「この署名は、この公開鍵に対応する秘密鍵で作られた」ということ

署名の検証だけではわからないこと

「この公開鍵の持ち主が誰なのか」ということ

攻撃者は、自分の秘密鍵と公開鍵のペアを作って、「これがAさんの公開鍵です」と言い、自分の秘密鍵で署名すれば、検証は通ってしまいます。

結論

認証局を使うのは、デジタル署名に何かを追加する、という話ではありません。

デジタル署名が成り立つための前提として、公開鍵と持ち主の対応を保証する仕組みが、そもそも必要だということです。

PKIの流れ

手順

発行前の確認
- 認証局は、申請者が本当にそのドメインを管理しているかを確認します
- DNSに指定された文字列を置かせたり、サーバに指定されたファイルを置かせたりする方法です
証明書の発行
- 認証局は「このドメインの公開鍵はこれです」という証明書を発行します
- 実際には、ルート認証局が直接サイトの証明書に署名するのではなく、ルート認証局が署名した中間認証局が、サイトの証明書に署名するのが一般的です
チェーンの検証
- 検証する側は、サイトの証明書から中間認証局の証明書、さらにルート認証局の証明書へと、チェーンを辿って署名を検証します
- ここで使うルート認証局の公開鍵は、サイトから受け取るのではなく、ブラウザやOSが最初から持っている信頼できるものです
署名以外の確認
- 証明書のドメイン名が、アクセスしようとしているURLと一致すること
- すべての証明書が有効期限内であること
- 失効していないこと

これらが揃って、初めて中の公開鍵を信頼できます。

この保証が崩れる場合

認証局の秘密鍵が漏れた場合
認証局が確認を怠って誤発行した場合
ブラウザの信頼する認証局の一覧が改ざんされた場合

補足：認証局だけが唯一の方法ではない

公開鍵の対応を保証する方法は、認証局だけではありません。

直接会って公開鍵を渡す
事前に安全な方法で配布する

ただ、不特定多数のサイトと初めて会う相手の公開鍵を保証するには、認証局のような第三者が必要になるため、WebではPKIが標準になっています。

署名で崩れやすいポイント

署名は、秘密にすることではない
- 暗号化されていないJWTでは、署名されたデータそのものは読めます
- 秘密にしたいなら、別に暗号化が必要です
- JWTのペイロードに個人情報やパスワードを入れてはいけない、というのはこの理由です
秘密鍵が漏れたら、否認防止は崩れる
- 作れる人が1人でなくなるからです
署名の検証だけでは不十分
- JWTであれば、有効期限、発行者、宛先も確認しないと、古いトークンや別サービス用のトークンが通ってしまいます

まとめ

ハッシュ：改ざん検知だけ。誰でも同じ値を作れる。
MAC：改ざん検知と認証まで。共通鍵を共有する二人だけが作れるが、二人とも作れるため否認防止はできない。
デジタル署名：改ざん検知、認証、否認防止まで。作れるのは秘密鍵の持ち主だけで、検証は公開鍵で誰でもできる。
デジタル署名の認証が成り立つには、前提として公開鍵の本物性を保証する仕組みが必要で、WebではそれがPKIである。

仕組み順で覚えようとすると混乱しやすいですが、目的から「どこまで届くか」で見ると、3つの方式の違いがすっきりします。