メールの暗号化はどこまで守る？PGP・S/MIME・SMTP over TLSを配送ルートで理解する

あなたがカフェで仕事をしていて、取引先の田中さんに「請求書.pdf」をメールで送るとします。送信ボタンを押しても、メールが田中さんのパソコンに直接飛ぶとは限りません。一般的には、あなたのメールソフト → あなた側のメールサーバ → 相手側のメールサーバ → 田中さんのメールソフトという順番で運ばれます。

このとき守り方は大きく2つ。配送トラックが走っている区間を守る方法と、荷物の中身を受取人にしか開けられない金庫に入れる方法です。

SMTPは電子メールを送信・転送するためのプロトコルです。SMTP over TLSでは、メールソフトとメールサーバ、メールサーバ同士といった接続の区間ごとにTLSで暗号化します。代表的な方法がSTARTTLSです。

例えば、会社のメールサーバが取引先のメールサーバへ送る間にTLSを使えば、その区間の盗み見や改ざんのリスクを減らせます。ただし、メールサーバは配送・迷惑メール判定・保存などのために本文を扱うので、TLSが使われても各メールサーバから本文が見えなくなるわけではありません。

この場合に使う証明書は、原則として接続先メールサーバを認証するTLS用の証明書です。利用者一人ひとりのメールアドレスにつき1枚、という仕組みではありません。なおメールソフトからの送信やサーバ間転送では、認証ポリシーや実装が異なります。

S/MIMEは Secure / Multipurpose Internet Mail Extensions の略称です。MIME（Multipurpose Internet Mail Extensions）は、文字だけではなく画像・PDF・添付ファイルなどをメールで扱えるようにする仕組み。そこに Secure（安全な）を付けた名前です。読み方は「エス・マイム」です。

たとえば経理担当の佐藤さんが、取引先の田中さんに「請求書.pdf」を送ります。普通のメールやSMTP over TLSだけでは、配送を担当するメールサーバが本文や添付ファイルを処理できます。そこでS/MIMEを使い、郵送する前に請求書そのものを鍵付きの箱へ入れるのです。

具体的な準備は3つです。①田中さんが公開鍵・秘密鍵のペアを作る。②田中さんは公開鍵とメールアドレスなどが結び付いた電子証明書（通常はX.509証明書）を用意する。③佐藤さんはその証明書を受け取り、発行元・有効期限・メールアドレスなどを確かめてから暗号化する。秘密鍵そのものは渡しません。

ここで認証局（CA：Certificate Authority）は、電子証明書への署名などを通じて「この公開鍵が誰に結び付いているか」の検証を支えます。ただし、CAがメール本文を暗号化するわけではなく、証明書があってもメールソフトで暗号化を選ばなければ平文のまま送られ得ます。

S/MIMEの電子署名は暗号化とは別の操作です。佐藤さんが自分の秘密鍵で署名すれば、田中さんは佐藤さんの公開鍵が入った証明書を用いて改ざんの有無などを検証できます。「田中さんの公開鍵で暗号化」「佐藤さんの秘密鍵で署名」と、使う鍵の持ち主が違います。両方を組み合わせることもできます。

PGP は Pretty Good Privacy の略称で、直訳すると「なかなか良いプライバシー保護」。暗号化ソフトの名称に由来します。OpenPGP は、その考え方をオープンな仕様として定めたものです。OpenPGPを実装する代表例にGnuPG（GPG）があります。現在のOpenPGP仕様の一つの基準はRFC 9580です。

たとえば友人の田中さんに、旅行の予約番号や身分証の写しを送るとします。田中さんは自分の公開鍵をあなたに渡し、秘密鍵を自分の端末に安全に保管します。あなたは田中さんの公開鍵でメッセージを暗号化し、田中さんだけが対応する秘密鍵で復号します。実際にはS/MIMEと同様に共通鍵を組み合わせて効率よく暗号化します。

フィンガープリント（fingerprint）は、日本語で「指紋」。OpenPGPでは公開鍵を元に計算した、鍵を識別するためのハッシュ値を指します。人間の指紋のように、一つの公開鍵をほかの鍵と区別するための値です。公開鍵そのものは非常に長いので、代わりに比較しやすい文字列を使います。

もし攻撃者が「田中さんの公開鍵です」と自分の公開鍵を送ってきたらどうなるでしょう。あなたが確認せず暗号化したメッセージは、攻撃者の秘密鍵で復号できてしまいます。暗号自体が強くても、間違った鍵を選ぶと守れないのです。

公開鍵の指紋を照合するときは、鍵を受け取ったメールへの返信だけで確かめず、以前から知っている電話番号・直接会う・信頼できる別経路を使うのが基本です。長いフィンガープリントを省略せずに照合し、途中の数文字が違うだけでも使わないようにします。

Web of Trust（信頼の輪）は、ほかの人が公開鍵と本人の結び付きを確認し、その鍵に署名する仕組みを利用して信頼を判断する考え方です。たとえば「以前から信頼している佐藤さんが田中さんの鍵を確認して署名している」という情報が判断材料になります。ただし、OpenPGPでは必ずこの方式で運用しなければならないわけではありません。直接の指紋照合、組織の鍵配布方法などもあります。

「公開鍵はメールアドレス単位か、サーバ単位か」という問いには、本文を受信者へ暗号化するS/MIME・PGP系は受信者の鍵、通信区間を保護するSMTP over TLSは接続先サーバのTLS認証情報と捉えると分かりやすくなります。ただしOpenPGPの鍵とメールアドレスの結び付け方、1つの鍵で扱うアドレスの数、TLSの鍵交換方式などは実装・運用によって異なります。

請求書の文章を自由に変更し、保護方式を切り替えてみてください。特に、SMTP over TLSの両区間をオンにしても送信元・送信先サーバでは本文を扱えること、S/MIME・OpenPGPではサーバ側に暗号化本文が届くことを確認できます。

請求書を送ります。振込先は当社の登録口座です。

「相手のメールが本物か」という疑問には、複数のレイヤーがあります。S/MIMEやOpenPGPの電子署名は、署名鍵に対応する公開鍵でメッセージの完全性などを検証します。一方、TLSは接続の保護であり、メール作成者本人の署名を直接保証しません。

またSPF・DKIM・DMARCは、送信ドメインのなりすまし対策に関係する仕組みで、メール本文を受信者だけに読めるようにする暗号化ではありません。DKIMにも電子署名技術が使われますが、S/MIMEやOpenPGPの利用者署名とは対象・目的が違います。

まず取引先と同じ暗号化方式に対応しているか確認します。S/MIMEなら相手の証明書を検証し、OpenPGPなら公開鍵の指紋などを別経路で確認します。次に秘密鍵の保管、紛失時の復旧方針、鍵更新後に過去メールを読めるかを考えます。

そして暗号化されるのは通常、メール本文・添付ファイルが中心です。一般的なメールでは送受信アドレスや件名などのヘッダ情報は保護されない場合があり、配送に必要な情報は引き続き見えることがあります。件名に機密情報を書かない運用も大切です。

最後に、両方は競合しません。本文をS/MIMEやOpenPGPで暗号化しつつ、配送路でもTLSを使えば、異なる場所の危険に重ねて備えられます。