企業がすべきフィッシング詐欺対策（最終回）

S/MIMEを使ったフィッシング詐欺対策

亀田 治伸
日本ベリサイン株式会社
システムエンジニアリング部 部長代理
2005/9/30

---

　前回は、現在策定が進められている送信者認証技術として「SenderID」と「DomainKeys」について解説しました。これらは、メールを送信したサーバを正しいと信頼する方法として注目を浴びています。

　しかし、実装は始まっているものの、まだまだ仕様が完成したとはいいがたく、いくつかの問題が残っているのも事実です。一方、フィッシング詐欺は切実な問題として存在しています。金融機関などの企業にとっては、何らかの対策を施さなくてはなりません。

　SenderIDやDomainKeysは、実際に存在しているドメインから送られてきたメールであれば、仮にそれが悪意に満ちたメールだったとしてもユーザーに届いてしまいます。1999年4月のレジストラの自由化以降、残念ながらドメインは偽名と捨てメールアドレスで簡単に取得できてしまいます（すべてのレジストラではありませんが、それが可能なレジストラが存在することは事実です）。

　また、これらはサーバ側のソリューションであり、ユーザーは自身で判断を行うすべがありません。それ故、3つ目の送信者認証技術である「S/MIME」に注目が集まっています。

S/MIMEの復権

　S/MIMEは、Secure/Multipurpose Internet Mail Extensionsの略で今年で誕生してから10年を迎えます。S/MIMEは、「メール本文の暗号化」「メール差出人（メールヘッダのFrom）の認証」「メール本文の改ざん検知」という3つの機能を兼ね備えています。

　また最大の特徴として、一般的なメールソフトに実装されている唯一のエンド・ツー・エンドの送信者認証技術であるという点が挙げられます。例えば以下のメールソフトがS/MIME対応となっています。従って、既にインフラはある程度整っているともいえます。

【S/MIMEに対応している主なメールソフト】 ・Outlook ・Outlook Express ・Netscape Messenger ・Thunderbird ・Mac Mail ・Lotes Notes ・Becky!Internet Mail

　S/MIMEに関してよく聞かれる話で代表的なものが、「S/MIMEはずいぶん前からソリューションとして存在していますが、なぜ、はやらなかったのでしょうか？ なぜ、いまになってS/MIMEなのでしょうか？」というものです。

　私はこう考えています。PGP vs. S/MIMEという比較がよく見られるように、S/MIMEは「メールの暗号化」手法の1つとして注目を浴びてきました。しかし、S/MIMEの暗号には弱点があります。それはメールを送る相手先（受取人）が証明書を持っていないといけないということです。

　例えば、ある会社が自社から送信されるメールをすべて暗号化したいと計画したとしましょう。この場合、取引先も証明書を保持している必要があります。その証明書に対して誰が費用を支払うのでしょうか。これがS/MIME普及の最大の障害であったと思います。

　いまの状況は変わってきました。インターネットは昔とは比べものにならないぐらい使いにくいものになってしまいました。これは「相手が誰か分からない」「自分が誰かバレない」という点に大きな問題があると思います。それ故、すでにインフラが整っているS/MIMEの持つ「送信者認証」技術がもう一度クローズアップされているのでしょう。

　DomainKeysでは、電子証明書を使用せず公開鍵と秘密鍵の鍵ペアのみで実装がなされます。サーバとサーバの間であればそれでいいかもしません。なぜならDNSサーバが間に介在しているためです。DNSにはサーバの管理者の情報が含まれています。

　でもこの仕組みをクライアントとクライアント間に置き換えてみると、間に介在するメールサーバが各個人の情報を保持しているでしょうか。ほとんどの場合、保持されておらず、仮に保持されていたとしてもそれが公開されることはまずありません。

　このため、クライアントとクライアント間では純粋な鍵のみでは相手を信用することができません。従って、代わりに誰かが「存在性」を「認証」し、証明する必要があります。その証明されたものが電子証明書といわれるものなのです。

電子証明書付きメール

　では、誰が相手を認証するのでしょうか。自分で自分を正しいということはできませんので、第三者認証機関といわれる組織が個人を認証し証明書を発行しています。以下に電子証明書の発行フローを記載します。

図1 電子証明書発行フロー

1. 企業は自身のサーバを認証機関に登録します
2. 認証機関は企業の情報を登記簿謄本、印鑑証明書、帝国データバンク登録情報などを使用し、その企業および担当者が確かに存在していることを確認します
3. 企業の担当者は発行された証明書を送信者のメールソフトに登録し、送信するメールに電子署名を付加します
4. 受信者のメールソフトがS/MIME対応である場合、送信者の認証が完了します

　送信するメールに電子署名を付与する場合の手順をOutlook Expressで見てみましょう。メールの新規作成画面です。標準設定で「署名」「暗号化」という2つのボタンがついています。

図2 メールの新規作成画面

　電子署名が付与されたメールは、リボンマーク付きのメールとして受信されます。リボンマークをクリックすると、電子証明書の内容が確認できます。

図3 電子署名された受信メール

　メールの差出人が「Harunobu Kameda」であり、「Harunobu Kameda」用電子証明書は「VeriSign」に保証されていることが確認できます。

図4 電子証明書の内容確認

　差出人が適当な電子証明書を作成し、メールを送付すると、受信者には次のような警告画面が表示されます。

図5 セキュリティ警告画面

　強烈なインパクトですね。なぜこうなるのでしょうか。ベリサインをはじめとする各認証局機関から発行された証明書は自動的にWindows（マイクロソフト製メールソフト）やNetscape関連メールソフトで信頼されるようになっています。このため、勝手に作成した証明書ではユーザーをだませません。

S/MIMEの弱点

　S/MIMEも問題を抱えています。それはWebメールおよび携帯電話のメール機能がS/MIMEに未対応であるということです。例えば、HotMailで電子署名付きメールを受信するとどうなるか見てみましょう。

図6 Hotmail

　拡張子が「p7s」のファイルが添付されています。電子署名データはメールヘッダに付与される添付ファイルとして既定されているためです。

Content-Type: application/x-pkcs7-signature; 　 　　　　　　　　 name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; 　　　　　　　　　 filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGg UAMIAGCSqGSIb3DQE （署名データ：略） gROgdVsvyp3Cq18o6cdGUs5aqqlN5PvIBuGyKoCtYxw9nQ kcPL56p2hz/QTyA73nAAAAAAAA

　携帯電話も含めてほぼすべてのS/MIME非対応メールソフトでは添付ファイルになります。ただし、NTTドコモの携帯電話だけは違う挙動をします。どうやらドコモ側のメールゲートウェイではあらかじめ登録された拡張子以外の添付ファイルが付いたメールは、本文と添付ファイルが削除された空メールとしてユーザーに配信されます。このため、ユーザーにメールは届くのですが本文も空白となってしまいます。

　企業の担当者がメールを送信する際、メールのあて先を見て、それがWebメールや携帯電話であるかどうかをいちいち判別するのは非常に面倒です。また、メールの大量一括配信などの場合も別の仕組みを構築する必要があります。それ故、S/MIMEを企業の仕組みに組み込むならば、電子署名用メールゲートウェイを構築するのが一番効果的な方法だと思われます。

　このスキームであればダイレクトメールの大量一括送信などへの適応も可能になりますし、ゲートウェイでdocomo.ne.jp、hotmail.comといったアドレスをはじくことが可能になります。

図7 自動署名ゲートウェイ

フィッシング詐欺対策は適所適材で

　今回の短期連載では、4つのソリューション（パターンマッチング、SenderID、DomainKeys、S/MIME）を紹介しました。ISPのような特殊な形態を除いた一般企業は、フィッシング詐欺対策としてどのような対策をいま、そしてこれから施すべきなのでしょうか。この問題は自社内に向けた対策とユーザーに向けた対策とで明確に区別する必要があります。

　まず社内向け対策としては、すでに導入されているウイルス対策製品のアドオンとして「パターンマッチング方式」の導入を一刻も早く行うべきだと考えます。ウイルス対策を導入していない企業は多くないと思いますので、これは比較的容易であると思われます。

　次にユーザーに向けた対策ですが、まずはエンドユーザーに直接メッセージを伝えられるS/MIMEが望ましいのではないでしょうか。もちろんインターネットのインフラに貢献するという意味で、SenderIDやDomainKeysの実装も行った方がいいのかもしれませんが、仕様が完全に定まっていない状態では一般企業にそれを要求するのは時期がまだ早く、少々酷なのではと思います。

　SenderIDやDomainKeysは素晴らしい技術ですし、将来的にデファクトスタンダードになるのは間違いないと思います。しかし、現時点での実装はかなりの負担がかかるものと思われます。また、ライブラリの提供方法やライセンスの問題など解決すべき問題は残っています。

　現実解としては、まずゲートウェイ型のS/MIMEエンジンを導入し、その後ゲートウェイ型としてSenderIDやDomainKeysの実装が統合された「統合メールセキュリティゲートウェイ」なる製品の誕生を待った方がいいかもしれません。その間、企業は自身がユーザーに果たすべき責任として、メールが持つ危険性とその対策の啓もうをし続けるということが大事でしょう。

関連リンク
	本物と偽物のサイトを組み合わせるフィッシング詐欺
	いまさらフィッシング詐欺にだまされないために
	フィッシング詐欺対策として企業が負うべき責任
	Sender IDはスパム対策の切り札となるか!?
	S/MIMEでセキュアな電子メール環境をつくる！

Security&Trust記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）