S/MIME 運用ガイドラインの策定に向けて

総務省　情報通信国際戦略局　通信規格課　標準化推進官（併任）情報流通行政局

情報流通振興課情報セキュリティ対策室

上原 哲太郎

Agenda

• 最近のサイバー攻撃におけるメール

• なぜ（今さら？） S/MIME なのか

• S/MIME 普及検討委員会の狙い

• 今後の予定

サイバー攻撃の変遷

• OS やブラウザの脆弱性の減少→ Office ， Java ， Flash ， PDF などの　　アプリケーション脆弱性を狙う例が　　相対的に増える→マルウェア送り込みの際　脆弱性を突くより　　　　　錯誤による実行を狙う方が主流に

• 攻撃の発端として錯誤による実行 or アプリ脆弱性を狙いなりすましメールが送り込まれる

なりすましメールによる被害

• フィッシング–システム管理者や各種サービス責任者を装う

（ ID/PW を奪うトリガなので）

• マルウェアの送り込み–普段の何気ないやりとりに紛れて…

なりすましメールの実例

Excel の脆弱性を突いて常駐キーロガを仕込む

画面のキャプチャを送信名前も電話も

実在

なりすましメールの被害を防ぐ

• S/MIME の利用– 最も古くからあるがあまり普及してない…

• SPF の利用– 現在最も普及しているがドメイン認証機能のみ– しかも弱い

• DKIM の利用– SPF に次いで普及だがドメイン認証機能のみ

• 番外：そもそもメールを使わない？

情報セキュリティ 2012 よりIV 具体的な取組１ 標的型攻撃に対する官民連携の強化等 エ 政府機関情報システムの効率的・継続的な情報セキュリティ対策の

向上( ｹ ) 政府機関から発信する電子メールに係るなりすましの防止（内閣

官房、総務省及び全府省庁） a) 内閣官房及び全府省庁は、悪意の第三者が政府機関又は政府機関の職員に

なりすまし、一般国民や民間企業等に害を及ぼすことが無いよう、送信者側及び受信側における送信ドメイン認証技術の採用を推進するとともに、国民に向けて広く周知し、受信側対策の一層の推進を諮る。また、 DKIMや S/MIME のように暗号技術を利用した対策の導入を積極的に検討する。

b) 総務省は、迷惑メール対策に関わる関係者が幅広く参加し設立された「迷惑メール対策推進協議会」や、国内の主要インターネット接続サービス事業者や携帯電話事業者が中心となって設立された民間団体である「 JEAG」等と連携して、送信側及び受信側における送信ドメイン認証技術（ SPF 、 DKIM 等）等の導入を促進する。

SPF,DKIM とは

• SPF– DNS を使って各ドメインが「送信 SMTP サーバ（の IP アドレス）」を広報

– 受信 SMTP サーバが送信 SMTP のIP アドレスと DNS 上の情報を比較して判定

• DKIM– DNS を使って各ドメインが「送信時にメールに付加す

る電子署名を検証するための公開鍵」を広報• 公開鍵暗号系だが PKI ではない（ DNS の信頼性に依拠）

– 受信 SMTP サーバがメールの署名を検証• メール受信者が署名を再検証することも可能• 本文の改ざんがないことも検証できる

SPF,DKIM の展開が先行• ISP や各企業団体主導で展開できる

– DNS および送受信 SMTP サーバにて対応可能システム管理側だけで展開でき一般利用者に負担をかけない

• その一方で限界もある– これまでのメール運用慣習上、

全ドメインの送信 SMTP サーバを完全に限定することは困難• 例えば個人契約 ISP の SMTP サーバから会社名義の From アドレスでメール出す人がい

る• SPF には「メーリングリストなどの転送メール問題」がある• そのため「必ずしも SPF,DKIM 認証が出来ないメールがある」ことを宣言する仕組みが

ある（ SPF の Softfail ， DKIM の ADSP unknown ）

• ただし「直接的広報メール」に限れば限定することは可能かも？

– ドメイン認証判定結果をメール受信者に伝える統一的 UI がまだない（結果がメールヘッダなどにあるが…）

S/MIME の現状• S/MIME は「教科書的な」 PKIベースのメッセージ交換方式– PKI で署名された電子証明書を各人が持つ想定– 電子署名と暗号の両方に使える

• 電子署名時は自己のメールアドレスに対応した秘密鍵でメールを署名して送信

• 暗号時はさらに受信者のメールアドレスに対応した公開鍵で暗号化して送信

• メールアドレス全体と本文の認証が可能• 多くのメーラが S/MIME に対応（ Outlook, Windows Live

Mail..., MacOS X Mail app, iOS も 5 から対応）• 電子証明書さえ導入すればいつでも使える状態• うまく普及すればメール暗号化の諸問題も解決

– 暗号化した添付ファイルのパスワードを別送する悪習を絶ちたい

• だが普及しているとは言いがたい

大きな阻害要因：電子証明書

• 各利用者に電子証明書を購入・導入させることが困難

• だが企業・組織からのアナウンスメールでのなりすましを防ぐだけなら十分運用可能では？– 発信者だけが電子証明書を持てばよい– 金融機関でフィッシング防止目的の実績あり

• 組織内で利用するだけなら可能では？• 最近流行の「クラウド化」：メーラのクラウド化

で風向きが変わるのでは？

そこで…• 「標的型攻撃対策のためのなりすまし防止」にフォーカスした

S/MIME運用ガイドラインを策定する– 最終的目標は国際標準化（IETFなど）

• まずは「企業や組織が外部に出すメールがなりすまされていないことを証明する使い方」に特化– 多くの人が電子証明書を導入せずとも済むモデルから始め

る– 組織内利用は次の目標とする

• そのために世の中のベストプラクティスを調査– 金融業界の他に例はないか？– 企業内利用で例はないか？

検討の現状

• 委託調査研究として発注– 「 S/MIME の普及方策に関する検討会」を組織

して議論• 座長：奈良先端大　門林雄基先生

– 委員は認証局事業者や ISP などから

– 「 S/MIME による電子メールのなりすまし防止対策に関するガイドライン（仮）」を策定中

– 同時に事業者等へのヒアリングを実施• ベストプラクティスの収集が主な目的

– うまくいっている例とうまくいってない例の両方

ここまでに見えてきたもの

• 広報に使うだけなら確かに導入は容易だが…– 金融機関は使っているが効果はよく分からない– メリットを感じる顧客はどれだけいるか？

• 小さな課題が山積している– 「このアドレスはS/MIME で送られています」

ということをどうやって広報する？– 署名されているメールを示すUI の不統一

• SPF,DKIMも同じ問題を抱えているので同時解決を– 過去のメールの署名確認のための電子証明書の扱い– SPF, DKIMとの共存はどう考えるか

• レベルによる使い分けか多重防御か

今後の予定

• 月末までに運用ガイドラインを作成–近いうちに公開

• 引き続いて残る課題を整理–特に UI の問題– DKIM との棲み分けを整理

• 次に標準化に着手–ガイドラインをどう広めるか

• さらに組織内利用→一般利用へ展開？

個人的な理想の姿

• 組織内で飛び交うメールが全てDKIM か S/MIME で検証可能な状態を保つ– DKIM か S/MIME かはコストメリット、求め

るセキュアレベルや暗号化ニーズで決まってくる• もちろん併用も可能

–そうすることで攻撃を察知しやすくなる• 組織間メールで暗号化が必要ならできれば S/MIME を使う方に誘導できないか？–少なくとも今のバッドノウハウはなんとか撲滅したい