高木浩光＠自宅の日記

■ Shuriken Pro3 のS/MIME機能に何があったか

確認された事象

まずこの広告ページにじっくり目を通して、S/MIME機能の有益さを理解する。

• Shurikenとは？ / 安全 / メールのデジタル署名対応！ , ジャストシステム
• Shurikenとは？ / 安全 / メールの暗号化対応！, ジャストシステム

次に、22日に発表されたJVN#B410A83Fを読んでみる。

• JVN#B410A83F: Shuriken Pro3 のS/MIME機能で署名検証時にFromアドレスが確認されない, JPCERT/CC / IPA, JP Vendor Status Notes, 2004年11月22日

「署名検証時にFromアドレスが確認されない」とはどういうことなのか、Shuriken Pro3/R.2の バージョン 5.0.1.6 で確認した現象を以下に書いておく。

まず、S/MIME署名されたメールを Shuriken Pro3 で受信し、表示しようとす ると以下の図にある画面のように、「このメールは暗号化、または、署名され ています。」というメッセージとともに「復号・署名確認」というボタンだけ が現れる。

この「復号・署名確認」ボタンを押すとどうなるかというと、正規のメール （なりすましも改ざんもされていない）であれば、そのままメール本文が表示 されるが、本文が改ざんされているときには、以下の図にあるような警告が現 れるようになっている。

また、偽の認証局から発行した偽の証明書で署名したメールを受信して表示し ようとしたときや、期限切れの証明書で署名されたメールを表示しようとした ときには、次の図の警告が表れる。

ところが、正規の証明書を使って、 他人のメールアドレスを発信者として騙ったメールを受信したときにどうなる かというと、以下の図のように、警告が出ることなくそのまま本文が表示され てしまうのである。

差出人欄が「info@example.com」というメールアドレス*1になっており、これはなりすましメール にほかならないわけだが、Shuriken Pro3 5.0.1.6 はこのとき警告を出さない。

これは脆弱性と言えるか

9月19日の日記にも書いたように、S/MIMEの仕様 では、From:またはSender:欄のメールアドレスと、署名に使われた証明書の メールアドレスが一致していることを確認することがMUSTと規定されており、 一致しない場合には、何らかのはっきりとした代替処理をする（証明書に あるアドレスを示すメッセージを表示するなど）ことがSHOULDとされている。

3. Using Distinguished Names for Internet Mail

（略）

Receiving agents MUST check that the address in the From or Sender header of a mail message matches an Internet mail address in the signer's certificate, if mail addresses are present in the certificate. A receiving agent SHOULD provide some explicit alternate processing of the message if this comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details.

RFC 2632 - S/MIME Version 3 Certificate Handling

この問題を修正するパッチが、ジャストシステムから11月16日にリリースされ たのだが、その修正内容がどのようにユーザに説明されたかというと、以下の ようになっている。

仕様変更項目

▼2004.11.16更新時に追加

S/MIMEの署名検証時に電子証明書内に記述されているメールアドレスとメール のFrom欄のメールアドレスが異なる場合に、自動で警告表示するようにいたし ました。

※メールの復号時に警告が表示されるため、 メール本文を読む前になりすましメールかどうか確認できます。

Shuriken Pro3 アップデートモジュール, ジャストシステム

この文は暗に、「メール本文を読んだ後ならなりすまし メールかどうか確認できたが」と言っているように読める。

たしかに、Shuriken Pro3のヘルプから、S/MIMEに関して説明されている部分 を見てみると、次の図のように書かれており、「表示」メニューの「暗号・署 名情報の表示」を選択することで、S/MIME署名の真正性を確認するという手順 が書かれている。

この操作をすれば、以下の図のウィンドウが現れるので、証明書のメールアド レスを目視で確認することができるというわけだ。

さて、これはどうなのだろうか？

改ざんされているときや偽証明書、期限切れのときには、警告が出るのだから、 それを知っているユーザは、警告が出なければなりすましメールではないと 誤認してしまうだろう。

ただ、そうした事態を見たことのない、そうした警告のことを知らないユーザ は、署名メールを受信したら必ず上の操作をしているはずだ……と言えるのだ ろうか。

たしかに、Shuriken Pro3のヘルプには次のように注意書きされている。

署名者の証明書が期限切れとなっていたり、無効になっていたりすることがあ りますので、［デジタル署名に使われた証明書］をクリックして、証明書自体 の有効性を別途ご確認ください。

Shuriken Pro3 ヘルプ

証明書が期限切れならばボタンを押した時点で警告は出るようになっているの に、期限切れになっていることがあるから、別途クリックして確認せよとされ ているのはちょっとわからないが、証明書が失効されていないかを確認するに は、そのウィンドウを出して、証明書を表示させ、「詳細」ボタンを押して、 「失効の確認」ボタンを押す必要があるようである*2。

どのように修正されたか

図5の説明には若干の補足が必要である。

受信したメールの署名者の証明書を、証明書ストア*3に信頼済みのものとして登録していない場合（たとえば、初めての相手 からのメールである場合）には、次の図のように、証明書ストアに登録するか と尋ねる確認ウィンドウが現れる。

これが From:を偽ったなりすましメールであるときに、この時点で気づくこと ができると言うことはできるのかもしれない。「詳細」ボタンを押せば、証明 書のメールアドレスを確認することができる。

フィッシング詐欺のメールが From:を偽ってきたときには、たとえそれが正規 の証明書で署名されていたとしても、この画面が現れるはずである*4から、 「詳細」ボタンを押せば本当の発信者メールアドレスを確認できる。

しかし、証明書ストアに既に登録している相手が、From:を詐称して別の人に なりすましてメールを送ってきた場合には、何もウィンドウが現れないままに 本文が表示されることになるのだから、やはり、この挙動は問題なしとはいえ ないだろう。

また、From:を偽ったフィッシング詐欺のメールに対して、図8の画面が現れた とき、「詳細」ボタンを押さないまま、「はい」を押してしまう危険もある。

「証明先」と書かれた部分には、メールアドレスが表示されておらず、証明書 の氏名部分が表示されているので、Class 1の証明書が使われている現状では、 ここには任意の名称を勝手に名乗ることができる*5のだから、もっともらしい名称を 名乗るフィッシング詐欺メールの証明書を、証明書ストアに登録してしまうか もしれない。

今回の修正パッチを適用したバージョン 5.5.6.0 では、「署名者のメールア ドレスと差出人のメールアドレスが一致しません」との警告が出るようになり、 From:を詐称したメールに対して図8のウィンドウが現れることはなくなった。 やはり、これが本来のあるべき挙動ではなかろうか。

こんな告知でいいのか？

さて、このような状況があったわけであるが、Shuriken Pro3のベンダーは、 今回の修正を「仕様変更」であると説明している。「セキュリティ」とか 「脆弱性」といった言葉を使ったユーザへの説明はなされていない。 JPCERT/CCと IPAが、これを脆弱性と認めて、JVN#B410A83Fとして発表 しているのにもかかわらずである。

ちなみに、6月30日には、こういう告知がなされていた。

• Shuriken Pro3、Shuriken Pro3/R.2、Shuriken Pro3/R.2 [ベリサインセキュリティメー ルセット]で、デジタル署名つきでメールを送信した際に、受信者側で警告が 表示される現象について

  Shuriken Pro3、Shuriken Pro3 /R.2、Shuriken Pro3 /R.2[ベリサインセキュリティメールセット]にて、デジタル署名付きメールを相互運用いただく際に、受信者側の一部の環境において警告メッセージが表示される現象を確認しました。なお、 現状のご使用においてセキュリティ上、安全性を損なう問題ではございません のでご安心ください。

このときのバグは、偽ではないはずのメールが偽と判断されてしまうという、 安全側に倒れているバグだった。だから、「安全を損なう問題ではない」とい うのは、たしかにそうだ*6。

こういうときには、専用の告知ページを設けて必死に事情説明をしていたくせ に、偽のものが偽と警告が出ない今回のような現象（つまり、危険な側に倒れ たバグまたは「仕様」）のときには、さらっと流して終わりのつもりのようだ。

しかも驚いたことに、今日、Shuriken Pro3のオンライン販売サイトで、ダウンロード購入してみたところ、 販売されていたバージョンは 5.5.4.0 で、このバージョンは、今回の問題点 が修正されていないものだった*7。

購入ページや、製品紹介のページに、今回の修正モジュールの適用が必要だといった説明はみあたらない*8。

こんなことでよいのだろうか？

ちなみに、11月17日にこういうニュースが流れていた。

• ジャストシステム、Shuriken Pro3のパッチを公開中止, PC Watch, 2004年11月17日

  不具合の内容は、「フォルダ-仕分けの設定」内で新規フォルダを作成するとShurikenが強制終了し、再起動後に同名フォルダが作成できなくなるというもの。

こういう不具合は発表しても、セキュリティ脆弱性の修正は発表されないらしい。

JVN#B410A83Fが出た にもかかわらず、それを報道したメディアは存在しなかったようだ。 マイナーなソフトウェアの脆弱性情報が報道されないというのならまだ理解 できるが、PC Watchの上の記事のように報道される製品ではある。

もし意味がわからないから報道できないということがあるのならば、 JPCERT/CC なり IPAなりに問い合わせればよかろう。

S/MIMEなぞ誰も使ってないし、S/MIME署名メールの真正性なぞ重要でもない——ということなんだとも考えられるが、 ならば、冒頭に挙げたベンダーの宣伝ページはなんなんだ、ということになる。

■ 偽の認証局証明書の作成が難しいという誤解があるらしい

10月30日の日記の続きだが、 鶴亀メールのサポートフォーラムでの作者氏の発言には続きがあって、

RFC全然読んでないです。すみません。Windowsのセキュリティ関係のAPIの説 明だけ読んで作っているし、さらに言うならテストも不十分です。というのは、 意図的に不正な証明書を作るテストをしてないです。

不正な証明書とか、不正な認証局とかを意図的に作るのって、難しいような…。（略）

鶴亀メー ルβテスト サポートフォーラム／鶴亀メール・バグ関係

と書かれていた。

不正な証明書を作る作業は、正当な証明書を作ることと何ら違いがないのだが、 そのことがあまり理解されていない様子がある。

証明書の元となる公開鍵暗号の鍵ペア（秘密鍵と公開鍵）の生成は、乱数をも とに生成するわけだが、これは、特殊な権限がなくても誰でも自由にできるこ とであり、opensslなどのコマンドを使ってできる。

これは、SSLのサーバ証明書などを用意するときに、サーバ管理者が自分で行 うべき操作であり、「サーバ証明書 openssl」などで検索すれば、その方法を 解説しているページが多数見つかる。

生成した鍵ペアを証明書にするには、認証局に署名をしてもらうわけであるが、 これも opensslコマンドを使って誰でも自由にできる。 それは、テスト用に用意されている機能だ。

自分で認証局証明書を作ることも、opensslコマンドを使って可能であり、ルー ト認証局は自己署名の操作をすればよい。

つまり、証明書が正当なものであるか不正なものであるかは、証明書を作り出 した時点で決まるものではない。 証明書が正当であるかどうかは、その証明書を使う側の人が、ルート証明書を 「信頼済み」として証明書ストアに登録しているか否かの違いでしかない。

たとえば、ベリサイン社が発行した本物の証明書であっても、ユーザが、証明 書ストアからベリサインの認証局を削除しているならば、そのユーザにとって それは「不正な証明書」であるのと何ら違いがない。

総務省の電子申請システムの解説でさえ、そういったことをわかっていない人 によって書かれていたことがあった。

上記のようなブラウザのサイトの信用性に関する表示については、誰が正しいと主張しているかを常に確認するようにしましょう。

（略）

総務省以外のサイトで、「ＭＰＨＰＴ　Certification　Authority」という名称の認証局が認証するサイトはあり得ませんので、このような表示が出た際には、サイトへの接続を中止するとともに、総務省に対しＵＲＬ等情報を提供いただけるようお願いします。

総務省「安全な通信を行うための証明書について」 （2002年12月の時点で掲載されていたページ）

認証パスが確認できないときに現れる警告について、「誰が正しいと主張しているか」など、信用性になんら関係がない。「誰が」の部分には任意の文字列を誰でも 自由に書き込めるのだということが理解されていなかった*9。

こうした観点でのPKIの解説というのはあまりみかけない。

PKIの解説というと、正常なケースでどうして真正性が確認されるかという 説明であったり、証明書の正しい作り方の手順の説明だったり、 あるいは、テスト証明書を使ったテストの方法の解説だったり、そういうの ばかりしかないように思える。

そうした正面からの解説では事の本質が理解されにくいようなので、 「こういう誤解をするな」という形式での解説が必要なのではなかろうか。