<前の日記(2004年11月24日) 次の日記(2004年11月29日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 1165   昨日: 3241

2004年11月27日

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

確認された事象

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

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

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

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

図1: S/MIME署名されたメールをShuriken Pro3で開こ うとしたときの画面

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

図2: メール本文が改ざんされているときに現れる警告

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

図3: 偽認証局から発行した偽証明書で署名されたメー ルを開こうとしたときに現れる警告
図4: 期限切れの証明書で署名されたメールを開こうとしたときに現れる警告

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

図5: From:アドレスを偽装したメールを開こうとした様子

差出人欄が「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署名の真正性を確認するという手順 が書かれている。

図6: Shuriken Pro3「ヘルプ」より

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

図7: 「暗号・署名情報の表示」機能を使ったときの様子

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

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

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

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

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

Shuriken Pro3 ヘルプ

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

どのように修正されたか

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

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

図8: 証明書登録確認の画面が現れた様子

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

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

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

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

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

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

こんな告知でいいのか?

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

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

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

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

図9: Shuriken Pro3アップデートモジュールのページ にある説明

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

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

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

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

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

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

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

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

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

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

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

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

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

と書かれていた。

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

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

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

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

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

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

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

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

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

(略)

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

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

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

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

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

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

*1 「example.com」 ドメインは、誰にも取得できないドメイン名として予約されたものであり、 このように例示のために使ってよいものとされている。当然ながら、 このメールアドレス宛てのメールを受信することは誰もできないのであるから、 このメールアドレスを発信者としてS/MIME署名されたメールなどというものは、 本来は存在し得ないはずである。

*2 自動で失効確認の 検査がされている可能性もあるが確認していない。

*3 Windowsの証明書 管理ウィンドウで「ほかの人」というタブで示されたところ。ここに登録する と、その相手へ、その公開鍵を使って暗号化メールを送ることができるように なる。

*4 フィッ シング詐欺師の証明書を、事前に証明書ストアに事前に入れている人など、 いないのだから。

*5 ここには、メールア ドレスを表示するべきではなかろうか。

*6 誤って偽と判断されるメールを普段から送っ てくる相手のメールを、警告が出ても本物と信じるようになってしまうことが あるという点では、安全性を損なっていると言えなくもないが。

*7 6月24日に作成されたファイルが配布 されている。

*8 購入ページに、「アップデートモジュールのダウンロードはこちら」というリンクはあ るものの、これは、「/R.2」への無償アップグレードの紹介をしているだけだ。

*9 総務省電子 申請・届出システムのこの珍解説は現在では撤回されているが、 「誰が正しいと主張しているか」で検索してみると、 いまだにこの間違った文章を掲載しているページがあるのがわかる。(1)国家公務 員人材バンク求人登録サイトでの解説 (2)内閣府電子申請・ 届出システムでの解説

本日のTrackBacks(全32件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20041127]

高木浩光さんの「■ 電子政府つくるは素人ばかり」の記事に衝撃を受け、少しづつPK

最近、S/MIMEの使えるメーラーで遊んでたりたりしていて、 高木浩光さんの日記の鶴亀メールの一件以降 JVNなど見ていたのですが、 S/MIME関係で2つの脆弱性情報が出ていました。 JVN#7C9208F1: Becky! Internet Mail におけるS/MIME の署名検証に脆弱性 11/25 JVN#B410A83F:..

先日紹介したネタの続きです。Shuriken や Becky にも同種の脆弱性が見つかったそうです。例によって高木さんとこから。 http://takagi-hiromitsu.jp/diary/20041127.html#p02 しかしここで取り上げたいのは、鶴亀メールの作者さんの発言。不正な証明書の件も十分にアレで..

検索

<前の日記(2004年11月24日) 次の日記(2004年11月29日)> 最新 編集

最近のタイトル

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|
<前の日記(2004年11月24日) 次の日記(2004年11月29日)> 最新 編集