S/MIME に対する誤った認識
— Security, trust, email — 15 min read
Facebook で「S/MIME 推進協議会」なるものが発足し，キックオフセミナーが開催されるとの投稿を目にしました．「S/MIME 推進協議会」の Web サイトを覗いてみたところ，S/MIME やそもそも暗号技術に対する誤った認識を元に作成したと思われる文章があったので，少し検証してみたいと思います．
本投稿の目的は，多すぎる問題点について明確化しキックオフセミナーでの質問ないしパネルディスカッションとして取り上げていただき協議会の皆さんの認識を確認すること，及びこのような誤った認識が一般に広まることを抑止することです．協議会や S/MIME に対する否定の目的はありません．
Web サイト全体にわたって不自然に思う表現や認識は多々ありますが，本投稿ではコアな部分に限って記述します．
疑問と問題点
「真正性」の定義
トップページなど Web サイトの様々な場所で「真正性」という言葉が使われています．
- この「真正性」の定義はなんでしょうか? 何をもって「真正である/ない」と判断できるのでしょうか?
メタな部分ですが，以降の認識に深く関わ ってきます．
デジタル署名及び署名検証プロセスの認識
会長挨拶より
一方、デジタル署名によりメールの作成者のなりすましやメール文の改ざんの検知機能の運用は、メール（特にニュースレターなど）の発信者だけが、公開鍵証明書を入手しデジタル署名を添付すればよいので実用化が簡単です。
との記述があります．この点について，
- デジタル署名は公開鍵ではなく秘密鍵を用いて生成されます．これは S/MIME に限らずデジタル署名を含む暗号技術の基礎です．
- 署名者・発信者は必ずしも公開鍵証明書を入手する必要はありません．
- むしろ受信者が公開鍵証明書を入手する必要があります．受信者は信頼する CA の発行する公開鍵証明書をもって署名を検証する事ができます．
- デジタル署名技術は署名が検証者によって検証されることで初めて意味をなし ます．S/MIME の普及及び実用化に当たってはここで述べられている署名者・発信者側の仕組みだけではなく検証者・受信者側の仕組みが必要であり，片方のみをもって「実用化が簡単」ということはありません．
BIMI 及び DMARC への認識
もし、SPF/DKIM/DMARC 対応のメール配信サービスから送信されたメールであることが受信者に明確になる方法があれば、そのメールはなりすまされていないということができますが、これは難しいです。企業から送信されるメールは様々であり、なりすましでないメールとなりすましメールを区別することは、受信したメールを注意深く確認するしかありません。
とされていますが
- この問題は BIMI で解決することができます．
- 実際に Gmail などの大手メールサービスプロバイダにおいても BIMI の検証・表示が実装されています．
また，同ページで
SPF/DKIM/DMARC は、送信側と受信側の双方でサポートしている必要があるので、なかなか心もとない状況です。
とされていますが
- S/MIME においても送信者側で署名の実施と公開鍵証明書の頒布，受信者側で公開鍵証明書の安全な入手と署名の検証を行う必要があり，このようなコストをもって特定の技術を「心もとない」などとするのは技術的及び運用的な観点が欠けています．
DKIM への認識
DMARC のベースになる DKIM の証明書は、基本的に第三者機関による本人証明をする必要がありません。独自のドメインで DKIM 対応のメールサーバ/DNS サーバを構築した場合、そこから送信されたメールは受信側で正しく認証されてしまいます。いわゆる「オレオレ証明書」となってしまう可能性があります。
とされていますが，
- そもそも DKIM では証明書を必要としません．
- そもそも DKIM は送信者側 MTA 運用者が自ら作成した鍵ペアについて，DNS 上で自律的に公開鍵を頒布するプロトコルであり，「オレオレ証明書」という言葉が与えるネガティブなイメージとは根本的に思想が異なります．
- S/MIME 証明書は PKI を利用したトラストチェーンにより root CA の公開鍵を信頼し root CA に依存することでチェーン全体を信頼できる特性があります．
- どちらも別の思想や目的を元に開発されたプロトコルであり，その特性を無視して技術を比較したり一方にネガティブイメージを植え付けることはナンセンスであり，同ページにも記載されているとおり「選択して使うということではなく両方使っていくこと」が可能で重要ではないでしょうか．
エンドツーエンドとは?
会長挨拶より
S/MIME（Secure / Multipurpose Internet Mail Extensions）が最初に提唱されたのが 1990 年代であり、デジタル署名によりメールの作成者のなりすましやメール文の改ざんの検知機能を持ち、また、エンドツーエンドでの暗号化による情報漏洩防止機能がある技術として注目され続けてきました。
とする一方で，同じ文章内で
また、使う人が増加すれば、暗号化メールを転送すると転送先では、復号カギを持たないので復号できないという問題も、最初に暗号文を受け取った人が復号し、転送するなら転送先の公開鍵で暗号化する機能を持たせることで対応できます。
としています．この点について，
- 転送の際に一度暗号化したものを転送者が解き，転送者の鍵で再度暗号化する方法では E2E での暗号化が達成されていません．
- このメールの転送という仕組みと暗号化の仕組みの妥協による手法は，冒頭にある E2E 暗号化とは目的や想定する脅威が異なります．
- 協議会はどのような目的でどのような S/MIME 実装を普及させたいのでしょうか? また，本来想定されたものと異なる使用方法を紹介するのであれば，その目的や想定する脅威が異なることも同時に紹介すべきではないでしょうか?
- この手法で署名も行う場合，最終的に転送された側が検証できるのは何の「真正性」でしょうか?
同様に，S/MIME の利用方法では
そこで、メールサーバーレベルで統一的に設定できるソリューションを使うことが推奨されます。
としていますが，
- 誰が何をもってそのようなソリューションを推奨しているのか不明です．
- 送信者のデバイス等ではなくメールサーバ (MTA) において S/MIME 署名を行った場合，エンドツーエンド (送信者-受信者間) での真正性の検証はどのように行うのでしょうか?
- 送信者-受信者間での真正性の検証を行わない場合，協議会が普及させたい「真正性」とは何でしょうか?
証明書があれば信頼できる?
S/MIME の利用方法ではページを通して「電子証明書が付与されていれば信頼できる」「電子証明書が付与されていなければ信頼できない」としています．
- 電子証明書が付与されていれば，たとえそれが改ざんされていたり，受信者の意図した送信者以外の電子証明書だったり，あるいは単純に電子証明書がファイルとして添付されているメー ルも信頼できるのでしょうか?
- S/MIME での E2E の真正性担保のためには受信者による電子署名の検証が必要です．そのために必要なのはメールに電子証明書が添付されていることではなく，電子署名が行われていることです．
- このような表現は読者に対し「署名検証を行って初めて真正性を確保できる」という根本的な概念ではなく「電子証明書さえあれば真正性を確保できる」という誤解を招きます．
- 単に電子証明書が添付されているだけのメールではどのような「真正性」が担保できるのでしょうか?
また，同様に電子証明書付きメールについてでは
メールソフトで受信したメールで、以下のように送信者の身元を確認することができます。 送信元アドレスが「xxx@s-mime.jp」であること。すなわち、s-mime.jp のドメインであること。 電子証明書の発行者が、以下であること。 JCAN Public CA1 – G4
とされていますが
- 上述したように，署名は検証されて初めて真正性を担保することのできる技術です．
- 署名検証のプロセスは送信元アドレス及び証明書の発行者の目視確認によって行われるのではなく，署名に対して公開鍵証明書を用いた検証アルゴリズムを適用する必要があります．
- 記載されている方法 は S/MIME の本来の使用方法とはかけ離れており，この方法をもってメールの真正性が検証されるべきではありません．
正しい認識の普及に向けて
会員一覧を見てみると，会員として参加している企業は有料の証明書発行やメール送信・署名アプライアンスの販売及びそのサポートなど，S/MIME の普及による金銭的受益者がほとんどです．この協議会が上述のような誤ったもしくはあやふやな認識を元に普及を語っている状態では「真正性の文化」を広めることではなく自らの金銭的利益が目的と捉えられてもおかしくありません．
その技術の普及にあたり自らがどのような利害関係にあるかに問わず，正確で利用者に寄り添った情報を発信できるかという点において，技術者倫理ないし企業倫理が問われるのではないでしょうか．\