インターネットバンキングの安全性向上に向けて〜メールの安全性確保を中⼼に〜⽴命館⼤学情報理⼯学部上原哲太郎第16回情報セキュリティ・シンポジウム⽇本銀⾏⾦融研究所 2015年3⽉11⽇インターネットバンキングへのアタックベクトルの多くにメールが  クレデンシャル（パスワード・電⼦証明書等）を奪って利⽤     フィッシング（メール）マルウェアを使ったクレデンシャル詐取総当たりによるものリスト型攻撃  マルウェアによる遠隔操作や通信書き換え  マンインザブラウザ(MITB)攻撃など  通信経路での中間者攻撃  通信内容の書き換え電⼦メール：不確かな通信⼿段  送信者メールアドレスのなりすましが容易  メールアドレスの正しさを証明する⼿段が普及してない  クライアント（MUA）から送信サーバ（MTA）への認証は必須ではない  MTA間の通信は認証も暗号化もされていない  通信路が暗号化されていない  MUA→MTAは暗号化(SMTPS)されていない場合が多い  MTA間も暗号化(SMTPS)されていない場合が多い  MTA→MUAは暗号化が増えた(POPS/IMAPS/HTTPS)が必須ではない  メールそのものも暗号化がされていない（end-to-endな暗号通信が実現できていない）  …なのにインターネットにおける標準的メッセージングツールの座から降りない！送信メールアドレスのなりすまし防⽌策  メール全体の電⼦署名技術を⽤いる   公開鍵暗号系を利⽤し、送信者が⾃⾝の秘密鍵でメールを署名し受信者はそれを確認してメールアドレスを含むメール全体の真正性を確認規格としてはS/MIMEまたはPGP  後者は公開鍵の真正性を受信者が確認する必要  ドメイン認証技術を⽤いる⽅法  SPF：送信側に使われるMTAのIPアドレスをDNSを⽤いて公告する   受信側MTAはDNSを⽤いて送信MTAのIPアドレスが公告されているかどうか調べ、そうでなければ判定結果をメールのヘッダに書くそれを MUAで処理 DKIM: 送信側MTAが鍵ペアを持ち、公開鍵をDNSで公告メール送信時には対応する秘密鍵でメール全体を署名しメールヘッダに⼊れて送信受信側MTAは署名を確認してその結果をヘッダに書くかまたは受信側MUAが直接チェックする実際に使われているのは…  最も普及してるのは SPF  ⾦融機関には S/MIMEを付加したメールを送っているところが多い  東京三菱UFJ  三井住友  みずほ  … http://member.wide.ad.jp/wg/antispam/stats /index.html.ja 総務省「標的型攻撃に対抗するための通信規格の標準化動向に関する調査結果」実は中⾝は「標的型攻撃対抗としての S/MIME導⼊指南書」 http://www.soumu.go.jp/main_content/000227896.pdf しかし…普及しない  S/MIMEの場合は標準化が進んでいるが…  ⾮対応MUAがある  多くのWebメール、ケータイメール  Windows 8の「モダンUI」のメールクライアント  Android標準のメールクライアント  送信側の証明書管理がそこそこ⼤変  SPFやDKIMは受信した後のMUAがどのようにユーザに結果を⾒せるか標準が存在しないその他の取り組み  迷惑メールの送信を困難にする  いわゆる送信サーバのreputation  ISPでSMTPが使う25番ポートをフィルタする  Out-bound port 25 blocking (OP25B)  送信クライアントへの送信者認証付SMTP利⽤とセットにすることが多い  メール以外のメッセージングサービス活⽤  SNSのメッセージ機能など