S/MIMEとメールの暗号化

技術の仕組み | メールの信頼

← 技術の仕組み

メールの守りは2つの層に分かれます。送信ドメイン認証は「そのドメインから正しく出たメールか」を受け取り側が確かめる仕組み。S/MIMEは本文そのものに署名と暗号化を施す仕組みです。役割が違うので、どちらかで代替できません。

先に押さえる

S/MIMEがやることは2つ。署名=差出人が本人で、中身が改ざんされていないと示す。暗号化=宛先だけが読めるようにする。署名は差出人の秘密鍵で作り、暗号化は受取人の公開鍵で行います。使う鍵が逆なので、ここを取り違えると設問で必ず外します。

署名と暗号化で、使う鍵が逆になる

署名する(差出人の鍵ペアを使う)

  • 作る:差出人が、差出人の秘密鍵で
  • 確かめる:受取人が、差出人の公開鍵で(証明書に入っている)
  • 示せること:差出人本人が書いた・改ざんされていない

暗号化する(受取人の鍵ペアを使う)

  • かける:差出人が、受取人の公開鍵で
  • 開く:受取人が、受取人の秘密鍵で
  • 示せること:受取人だけが読める

つまり署名は差出人の鍵ペア、暗号化は受取人の鍵ペアを使います(返信では役割が入れ替わりますが、かけるのは受け取る側の公開鍵・開くのは受け取る側の秘密鍵という対応は変わりません)。したがって、暗号化して送るには、先に受取人の証明書が要ります。設問では「まず署名付きメールをやり取りして互いの証明書を得る」という段取りが出てきます。これは手間ではなく仕組み上の前提です。

登場人物は差出人と受取人の2人。鍵は4本あり、秘密鍵は本人だけ、公開鍵は証明書として配る。

差出人
差出人の秘密鍵差出人だけが持つ/差出人が署名を作る・差出人宛の暗号文を開く
差出人の公開鍵(=差出人の証明書)誰に渡してもよい/受取人が署名を検証する・受取人が差出人宛に暗号化する
―
受取人
受取人の秘密鍵受取人だけが持つ/受取人が署名を作る・受取人宛の暗号文を開く
受取人の公開鍵(=受取人の証明書)誰に渡してもよい/差出人が署名を検証する・差出人が受取人宛に暗号化する

主語を「差出人」「受取人」に固定すると、鍵の入れ替わりは1行で言えます。差出人は自分の秘密鍵で署名し、受取人は差出人の公開鍵で検証する。受取人が差出人へ暗号化するのも差出人の公開鍵で、開けるのは差出人の秘密鍵だけ。つまり秘密鍵は本人の手元から動かず、相手に渡るのは公開鍵(証明書)だけです。

動きで見る

署名付きメールを1往復させるだけで、差出人と受取人がそれぞれどの鍵を使ったかと、暗号化した瞬間に経路の検査が効かなくなることが同時に見えます。(図は横スクロールできます)

つまずきポイント

本文を暗号化すると、経路上の装置が中身を見られなくなります。ウイルス検査や情報漏えいの検査をメールサーバで行っている場合、それらが素通りすることになります。設問はここを突いてきます。対策は端末側で検査するか、いったん復号して検査する仕組みを置くか——どちらも「見える場所をどこに作るか」の話で、TLSの傍受と同じ構図です。

層が違うので、両方要る

1守る対象が違う
送信ドメイン認証「このドメインから出たか」を受信側が確認する(差出人の詐称対策)
↓これだけでは、中身の改ざんも盗み見も防げない
S/MIME本文に署名・暗号化。本人が書いたかと宛先だけが読めるか端から端まで守る
見抜きどころ

答案では「送信ドメイン認証はドメイン単位、S/MIMEは差出人個人と本文」と切り分けます。もう1つの定番は証明書の失効確認で、退職者の証明書が失効しているかを確かめなければ、過去の鍵で署名されたメールを信じてしまいます。「署名を検証する」だけでなく失効を確認するまで書けると強くなります。

運用でつまずく所

全員に証明書を配る必要があり、発行・更新・失効・端末への導入が回らないと定着しません。設問でも「利用者が増えたときの運用負荷」が論点になります。範囲を社外とやり取りする部署に絞るといった現実的な落としどころが用意されていることが多いです。

つながる仕組み

ドメインの層← 送信ドメイン認証 証明書の有効性証明書の失効確認 →

この仕組みを使う設問